Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- TinyTrak
- Messages
Search
|
Micro-Trak Products Update
I promised quite a number of people that I would let them know about the status of a couple of products in the Micro-Trak Line. Many of the Micro-Trak products had to be redesigned due to parts becoming extinct. Apparently there was a flu or something going around, and certain parts manufacturers went belly-up, made undocumented changes to the their parts, or just raised the prices. In the case of some amplifiers the parts increased by 500%! This caused us to pull a number of our products until we could obtain new parts, or acquire the current parts inexpensively enough to build the products at a price point that is not awful. The RTG-50 ( Originally called the "BFT"-50) is in production, but with somewhat reduced power. The new version, identical in almost all other respects to the old version, uses a different amplifier module, and has an output power of between 30-40 Watts, depending on your power supply voltage. With an alternator running at 14 Volts, it will typically produce 40 Watts, but we are calling it the RTG-30 so as to not appear like the CHICOM Walkie-Talkie people who claim handhelds with 25 Watts output. I have already sent Byon a number of these, and I expect he will put it back on the Byonics webstore shortly. The firmware and the configuration software are the same as before. Like the last generation of RTG-50's, these RTG-30's have thermostats that will shut off the amplifier if they reach 50C. ( Still, try to remember to turn off the tracker when you remove your antenna)? The reboot of the? MT-AIO is in the works too. One of the reasons that it disappeared was that Pelican, after about a hundred yeas making the same stuff, decided to drop the Yellow case we have used for the last decade. We redesigned the unit fit in another manufacturers case, whereupon they dropped the whole family of cases from production ( Flambeau, "Black Ribbon" cases)? I found a case that I liked a few months ago, and have been quietly working on a next-gen version of the MT-AIO. The prototype is smaller and lighter, and works well. Since a whole new? generations of Hams has come on to the scene, I decided to rethink a lot of the design elements. Like Neanderthal Man, we had built the unit around running on alkaline batteries. With Alkaline batteries, the output voltage decays with operating time. I decided to plan this unit around operating with four, 18650 LiPo batteries. With protected 18650 batteries (These have a built-in little circuit to protect the batteries from going up like Hiroshima, and not catch fire when charging) the limitations on supply current cap the unit at about 12 Watts output. With unprotected batteries, the unit runs at about 20 Watts initially, tapering to about 16 Watts before the batteries run out. LiPO's run more or less flat until they are discharged completely, and then just stop working. In bench testing, where I have the limitation of no view of the sky, the unit ran about four days, with the standard two minute transmission interval, and "sleeping" the GPS between transmissions. It will do better of course if its outside and has a view of the sky. Like most of the Micro-Trak APRS transmitters, the output power is trimmer-pot adjustable. At any rate, I have the first run of boards being run now, and hope to have saleable products in Byon's capable hands soon. I will put up photos of the new production units as soon as I put one together. 73, Allen AF6OF VHS/BYONICS |
|
Re: Peet bros 2100 wx station with TT3
Hi, Dean here again, I¡¯ve gotten no reply so I guess my difficulties are obvious or common. But not to me, and I used hold down a pretty technical job but since a stroke things are harder. That said this project wouldn¡¯t be yet another wx station on air but would preclude 2hrs of driving for some the Gang by checking site before driving out. Nearby wx stations are sometimes unreliable and even 1/4 mile away can be completely different wx conditions.
toggle quoted message
Show quoted text
So if anyone wants to contribute to my solution I can pay a stipend we can setup before hand. I promise to try not to be a pain. Dean NL7TK. On Jun 10, 2023, at 10:39 AM, Dean Gramling <dgramling@...> wrote: |
|
Peet bros 2100 wx station with TT3
Hi, I have three TT3 transmit devices and peet cables for serial to TT3 and from TT3 to radio. I have never gotten success transmit out to 144.39 net so never see my station and wx information on aprs.fi my oldest TT3 I flashed successfully and set up as NL7TK-13. I have never been successful using windows 10 and Tera term while following read me file to the letter. (On newer TT3)
Questions: do you have any suggestions. And is there a terminal program compatible with windows 11? I¡¯m assuming peet 2100 keyboard is working as I saw it out put wx strings normally at Hamvention this year while at peet booth. Was hoping to see Byronic booth but either missed it or no show. Thanks in advance, Dean NL7TK |
|
Re: TT4 with Peet Weather Station and APRS map
I have not worked with AGW much, but several users say it is easier to implement than KISS - especially with multiple 'streams'.
Also, I have only really worked on the decode side of the equation. I think of KISS as the wrapper around the AX.25 protocol to include TNC instructions and other information (like data stream in multi-stream connections). Most of my decode experience has come from the Direwolf github code and discussions with WB2OSZ (on the Direwolf discussions of groups.io). ? ?mainly kiss_frame.h and kiss_frame.c I am not much of a coder, but I hope this helps. ------- Rob KB8RCO |
|
Re: TT4 with Peet Weather Station and APRS map
Rob and the group, One more question regarding you last message: I am trying to get a better understanding of KISS over TCP or AGW.? Where does KISS and AGW and AX.25 fit into the 7 layer OSI model??? Then where does KISS fit in.? And what is AGW?then?? Thanks!!! Sent from Proton Mail for iOS On Sun, May 21, 2023 at 12:05 AM, Rob Giuliano via groups.io <kb8rco@...> wrote:
I think an interface of sensors would be a worthy project. publicKey - [email protected] - 0x54215193.asc
publicKey - [email protected] - 0x54215193.asc
signature.asc
signature.asc
|
|
Re: TT4 with Peet Weather Station and APRS map
Rob, and the group,? I have a Java class method working that generates the TEXT version of an APRS weather object from a universal?sensor Interface class.?So I can go straight into the TT4 without having to convert the data to PEET mode.? But now I am trying to figure out how to make a KISS sentence, from a received?APRS sentence,?because the APRS client in LinBPQ appears to require KISS mode data.? Can you advise?: 1: does my interpretation make sense? I am not sure if I am understanding the big picture.? 2: if so, do you know of a KISS encoder that may be available that can take in TEXT and generate KISS data? Otherwise I will write one myself.? 3: do I need to be concerned with AX.25 encoding? Sent from Proton Mail for iOS On Sun, May 21, 2023 at 12:05 AM, Rob Giuliano via groups.io <kb8rco@...> wrote:
I think an interface of sensors would be a worthy project. publicKey - [email protected] - 0x54215193.asc
publicKey - [email protected] - 0x54215193.asc
signature.asc
signature.asc
|
|
Re: MT-1000 - modifying for reception
Rob, Take a look inside your MTT4B, pretty much the same module as the MT-1000. Allen On Tue, May 23, 2023 at 2:29?PM Rob Giuliano via <kb8rco=[email protected]> wrote: On Tue, May 23, 2023 at 05:26 PM, Rob Giuliano wrote: |
|
Re: MT-1000 - modifying for reception
Rob, The MT-1000 is a transmitter-only, but it has a transceiver module in it. The RX is kept off to save battery power, since holding off transmissions based on a busy channel is a non-starter for a transmitter that is designed for high altitude operations. The same unit product, less the APRS specific stuff ( GPS, temperature sensor, etc) is also used for our MF-PC Fox hunt transceiver, which may be programmed and remotely controlled via DTMF tones. The same RF module is also used in the MTT4B's ( On production hold currently) and the DTMF receiver decoder called the DTMF Remote (). The DTMF remote is what I would usually recommend for? controlling an HAB, since you can control determine the control frequencies for command controls and ACK's as well as CTCSS and DCS, so there is little chance anyone will cut down your payload with an "accidental" APRS command. ( Its much more fun to take down HAB's with 2 Million dollar missiles)? 73, Allen AF6OF
On Tuesday, May 23, 2023 at 02:05:17 PM PDT, Rob Giuliano via groups.io <kb8rco@...> wrote:
I am pretty sure All the MicroTrak products are TX only.? So the MT8k is a transmitter - not transceiver. You would need an MTT4B to get a transceiver. Robert Giuliano
On Tuesday, May 23, 2023 at 04:45:47 PM EDT, va1qle@... <va1qle@...> wrote:
Hello, I have an MT-1000 which I'm planning to use on a high altitude balloon. I was wondering if it was possible to configure it to keep the transceiver on at all times. That way, I can tap the audio from the unit and run it through a demodulator, so that I can use APRS packets to control the balloon from the ground. I would use a second transceiver for reception only, but I'm worried about blowing its frontend with it so close to the MT-1000. Thanks! |
|
Re: MT-1000 - modifying for reception
Using the RX function would not be impossible, but it would not be very practical either. It would take convincing Byon to write substantial new code to set the parameters for the receiver. It might be possible to just llift p the pin on the PIC that controls the PD ( Power down), which in the MT-1000, is used to put the transceiver to sleep between transmissions. I think, and this is only an unverified thought, that this would give you un-squelched audio but only on 144.390 MHz There is no provision in the configuration software to change the RX frequency. Don't hold me to this!? FYI, we do have a few more MTT4BT-Mini's, which we built originally for a government contract. These are pretty much a stripped down version of our MTT4BT transceivers. You might want to take a look at the product and the it's manuals to see if that would work out in your application a little more elegantly. ()? 73, Allen AF6OF
On Tuesday, May 23, 2023 at 01:45:48 PM PDT, <va1qle@...> wrote:
Hello, I have an MT-1000 which I'm planning to use on a high altitude balloon. I was wondering if it was possible to configure it to keep the transceiver on at all times. That way, I can tap the audio from the unit and run it through a demodulator, so that I can use APRS packets to control the balloon from the ground. I would use a second transceiver for reception only, but I'm worried about blowing its frontend with it so close to the MT-1000. Thanks! |
|
Re: MT-1000 - modifying for reception
I am pretty sure All the MicroTrak products are TX only.? So the MT8k is a transmitter - not transceiver. You would need an MTT4B to get a transceiver. Robert Giuliano
On Tuesday, May 23, 2023 at 04:45:47 PM EDT, va1qle@... <va1qle@...> wrote:
Hello, I have an MT-1000 which I'm planning to use on a high altitude balloon. I was wondering if it was possible to configure it to keep the transceiver on at all times. That way, I can tap the audio from the unit and run it through a demodulator, so that I can use APRS packets to control the balloon from the ground. I would use a second transceiver for reception only, but I'm worried about blowing its frontend with it so close to the MT-1000. Thanks! |
|
MT-1000 - modifying for reception
Hello,
I have an MT-1000 which I'm planning to use on a high altitude balloon. I was wondering if it was possible to configure it to keep the transceiver on at all times. That way, I can tap the audio from the unit and run it through a demodulator, so that I can use APRS packets to control the balloon from the ground. I would use a second transceiver for reception only, but I'm worried about blowing its frontend with it so close to the MT-1000. Thanks! |
|
Re: TT4 with Peet Weather Station and APRS map
I think an interface of sensors would be a worthy project.
If it is already working on 2 ports, then you ave solved the single device - 2 application problem. I am not familiar with LinBPQ and its capabilities, but APRS telemetry has a lot of value.? Although weather packets are telemety packets, they are handled differently - especially by aprs.fi and clients.? However, aprs.fi has some nice visuals (just like weather data) for telemetry data that is not weather related. So, if you use KISS over TCP (or AGW), the data coming from your script to 'any' client would be generic, and most applications (such as APRS) would handle it as a remote TNC or RF port.? This would be very generic and easy to interface with on many levels. ? Creating Telemetry packets as well as weather packets could make it truly generic for other sensors (non-weather such as battery voltages, etc.) Two sources for info: ?? APRS101.pdf => info on KISS packets ?? Direwolf code source and Telemetry Toolkit -> C++ code and examples for external formatting of data. |
|
Re: TT4 with Peet Weather Station and APRS map
Hi guys,
Please pardon me, as I responded to Rob's latest post before I read the previous posts, so please disregard any confusion. Your comments sparked this thought: I could certainly use what I have now, and write an interface from Ecowitt to KISS, and split a single port, all in KISS mode. But that is ugly. However, it may already be working on two ports, as Alan suggested...... I will configure the TT4 CDMODE as Alan recommends, and test. I can certainly? generate local packets on my Yeasu VX-8G, including GPS location, for testing. Not to be too crazy, but I have another idea now....Please advise on your thoughts: It may make sense to organize all my code into an aprs-daemon, something along the lines of gps-daemon (gpsd) project. But instead if consuming NMEA GPS data, like gpsd, the arpsd server would consume, through a standardized Java interface class, data from any number of weather sensors. I currently have native Java classes working that can read Ecowitt WS90/GW2000b, Bosch BME280 over I2C, the DHT sensors, and a Vishay VEML6075 UV sensor over I2C That is because those are the only sensors I have at the moment. But the Interface Class makes it easy to add more. So, in summary.... I could add an Interface to my TCP server that sends sensor data over a TCP pipe, to interested clients. That is exactly what the Ecowitt GW2000b already does for their entire suite of sensors. But the Ecowitt API is very unclear, and my Mandarin is a little, shall we say, "rusty," so I had to do extensive trial and error. But I have other discrete sensors that are I2C or PWM or analog devices, as I just mentioned. Thus the need for an interface to my TCP server. This is the tricky part: Write a TCP client and add methods to convert the TCP server stream into something that looks like 2400 baud Peet weather station data (already done, as previously discussed), or KISS formatted standard APRS messages for transmission by way of a tty or USB port (Still needs to be done). With the object oriented Interfaces, it make the server and clients highly extensible. Do you think this might be a worthwhile or useful project? Thanks yet again! John N1CTF |
|
Re: TT4 with Peet Weather Station and APRS map
On Sat, May 20, 2023 at 09:21 PM, John - N1CTF wrote:
If the TT4 can not support dual modes at the same time, then I will need to add a method to my Java translator that goes from Peet -> KISS. (Probably something I should do, anyway - just to make it more possible useful to other folks.)????? Ecowitt -> LAN (eth) -> Pi#1 (Java Ecowitt -> Peet translator) -> /dev/ttyUSB0 -> [TT4 (port B in BMODE=PEET) -> TT4? (Radio Port)] 144.390 TX only [This work well, currently as N1CTF-2 on aprs.fi) ????? 144.390 Rx Only -> [TT4 (Radio Port) -> TT4 (Port A in AMODE=KISS)] -> /dev/ttyUSB0 -> Pi#2(APRS/LinBPQ - KISS 19200 baud tty /1200 baud AX.25 RF) The issue is not that the TT4 can not support dual mode.? It cannot support dual mode on the same port.??? You are using both ports. ? TT4 J2 pin 8 (Port B IN from Pi/Java) goes to /dev/ttyUSB0 Tx and tt4 J2 pin 3 (port A OUT to Pi) to /dev/ttyUSB0 RX? That leaves 3 issues: 1. Did you fully configure the receive (Monitor/RXAMP) so that the data is being sent properly? 2. Both application (Java and LinBPQ) need to be set to the same baud rate - as do the TT4 port A and port B ??? You don't state the baud rate for the PEET, but it needs to match the KISS port.? Both at 19200? ??? Since both are going into the same /dev/ttyUSB0, the baud rates need to be the same. 3. You have the 2 applications (Java and LinBPQ) sharing /dev/ttyUSB0. ? ? Physical RS232 ports are not really built to work this way. Although #1 is required under all circumstances, writing the Java code for KISS won't fix #3 -> unless you feed the data through LinBPQ. The better fix is 2 USB-to-RS232 devices and the full TT4 style port splitter (A/B with each having both TX and RX) on the same Pi.? Example: LinBPQ using /dev/ttyUSB1 and connected to TT4 Port A (KISS / 19200) ???????????????? Java using /dev/ttyUSB0 and connected to TT4 Port B (PEET / ####) ??????????????????? Nothing has to change with your Java script ------- Rob KB8RCO |
|
Re: TT4 with Peet Weather Station and APRS map
John, The TT4 is most commonly used with split modes on each port. Generally, its GPS on one port and computer/KISS on the other. If you are not decoding APRS traffic off the air, don't panic; the procedure?for setting up the TT4 to do this is well documented. I suggest starting?with very low radio volume and the default receive settings for the TT4 ( RXAMP, etc.) with the exception of CDMODE, which should be set to TONES, and you should run your radio receiver with an open squelch. Just because you hear packets, don't expect to decode them all...the signal needs to be 5/5 or it won't decode. If you can generate a local packet?for testing, it makes the set up for receiving a lot easier. 73, Allen AF6OF On Sat, May 20, 2023 at 6:21?PM John - N1CTF via <john.chartkoff=[email protected]> wrote: Ron, |
|
Re: TT4 with Peet Weather Station and APRS map
Ron,
My code for the translator is attached, if you may be interested. My apologies, as it was a rather unclear explanation. Yes, that is basically what I am trying to do, except this is the precise picture: Ecowitt -> LAN (eth) -> Pi#1 (Java Ecowitt -> Peet translator) -> /dev/ttyUSB0 -> [TT4 (port B in BMODE=PEET) -> TT4? (Radio Port)] 144.390 TX only [This work well, currently as N1CTF-2 on aprs.fi) ...AND, CONCURRENTLY ... 144.390 Rx Only -> [TT4 (Radio Port) -> TT4 (Port A in AMODE=KISS)] -> /dev/ttyUSB0 -> Pi#2(APRS/LinBPQ - KISS 19200 baud tty /1200 baud AX.25 RF) So, I am, essentially, trying to use the same TT4 and radio to send Peet weather data in Peet mode (transmit only) on port B and receive? APRS messages (receive only) on Port A, but in KISS mode. I have it connected this way now, but it is not working.So, I am asking this question: Is this something that should work on a TT4? (That is to say KISS mode AND Peet mode at the same time but on different ports.) If so, then I must have something incorrectly configured. To be clear - there are two RPi's: one is a translator and weather info display on a 7" display. The other RPi is running the LinBPQ/APRS instance. If the TT4 can not support dual modes at the same time, then I will need to add a method to my Java translator that goes from Peet -> KISS. (Probably something I should do, anyway - just to make it more possible useful to other folks.) Then, build a hardware splitter that splits TT4 port A (A-MODE=KISS) jack into two parallel DE9 ports,and pick off TX for the weather station on one parallel and Rx for the LinBPQ machine on the other parallel. But, that might be kludgy... Or, less of a kludge would be to put everything on the same Pi and convert the Ecowitt to KISS APRS weather statements, and forget the parallel adapter, and Peet mode, and use just one port. But then, I will not have an independent weather station and an independent LinBPQ/APRS RMS relay system. Sorry if I just gave you a headache :) Thanks again for your help!!! 73' John N1CTF |
|
Re: TT4 with Peet Weather Station and APRS map
As Allen said, it really isn't good to split TX and RX on the same port, and in your case, they would be using different modes. There is another option (same mode): ?? Since you are already 'intercepting' the weather data with the Pi, and reformatting it to PEET, ????? why not generate the full weather message (KISS)? and send it to the TT4 to transmit? ?? If you generate the message in KISS, you could send it over the same port as the APRS/LinBPQ. ?? The "magic" would come in sharing the TT4 serial port on the Pi, or getting the weather data message to a APRS/LinBPQ client that would just pass it on. It would look something like this: ?? Ecowitt hub data -> /dev/ttyUSB0 -> Pi (Pi converts it to weather KISS packet) -> /dev/ttyUSB1 -> TT4 -> Radio????? (one way) ?? Radio <=> TT4 <=> /dev/ttyUSB1 => Pi (APES/LinBPQ)???????????????????????????????????????????????????????????????????????????????????????????????????????????? (two way) NOTE: several APRS clients will accept a "WXNOW.txt" file and transmit the data.? I do not know if LinBPQ clients do the same ?? If you have that capability, it would look like: ?????????? Client does normal operation >?? Radio <=>
TT4 <=> /dev/ttyUSB0 <=> Pi app ? ?? ? ? ?? ? Ecowitt hub data -> Pi (Pi converts "WXNOW.txt" file) ->
client read file? and TX as needed.Robert Giuliano KB8RCO
On Saturday, May 20, 2023 at 11:46:24 AM EDT, vhsproducts via groups.io <vhsproducts@...> wrote:
Is the root question essentially whether you can feed one Port PEET data and receive Data from your radio's audio on the other Port as KISS? It may be a trick question, but it seems to me the answer is simple: Yes, you can do that.? You can't "split" one port's TX and RX channels into independent protocols, but you can split that of each port. How you developed the PEET data with your magical network wizardry should not effect this as far as I can see.? 73, Allen AF6OF
On Saturday, May 20, 2023 at 07:59:36 AM PDT, Rob Giuliano via groups.io <kb8rco@...> wrote:
I am not quite following this idea. The TT4 has 2 ports, so you can make 2 connections -> ?? B. Peet Weather ?????? You appear to have something setup like this:?? Peet -> Pi (Java) -> TT4 (port B) -> Radio ?????? Note:? this is one way traffic.? Nothing from the Radio or TT4 goes to the Peet - won't do anything with it anyway. ???????????????? You don't mention how you have the Peet -> Pi and Pi -> TT4 connected. Two USB to RS232 dongles like this ???????????????????????? Peet -> /dev/ttyUSB0 Pi (Java) /dev/ttyUSB1-> TT4 (port B) -> Radio? ?? A. Where do you want the TT4 port A to go? ?????? If you are trying to get that into the same Pi, you will need a third USB to RS232: ???????????????????????? Pi (APRS/LinBPQ) /dev/ttyUSB2 <=> TT4 (port B) <=> Radio? ?????? Note:? this is two way traffic.? traffic to and from the Radio go through the TT4 to the attached computer. All settings for the APRS/LinBPQ would have to reference the 3rd (/dev/ttyUSB3) device. Is that what you are trying to do? ------- Rob KB8RCO |
to navigate to use esc to dismiss