Hello,
?I saw the note about giving my call sign so here it is: KD9AER

I have been asked to resurrect our clubs Micro-Trak 8000 FA for an HAB launch so will be asking for links to programming software downloads and pinout diagrams for the required cables.

73,
Steve Grob
KD9AER

Hey Rob,
Many thanks for your research! It is most appreciated.

I have it working.

The fix was to use a different generic USB -> Serial Port adapter.

The moral of the story: you must always use a Y adapter that implements the full RS-232 standard, or use a cheap USB -> Serial adapter that ignores handshaking.

My (overly complicated) analysis:

The problem appears to be that I was not setting the handshaking (also known as "flow control")? lines.
I found the schematic for the official Byonics Y adapter on SpudGunMan's Git site.
The official Byonics adapter has the CTS jumpered to the Ready to Send (RTS) line, and the Data Set Ready (DSR) line jumpered to the Data Terminal Ready (DTR) line. These jumpers make up for the fact that the TT4 is not fully RS-232 compliant. This is for the "A" port on J2, which is intended for data terminal equipment (DTE) which we now call a "computer" and not a "terminal."

On the "B" port, they don't have any lines jumpered, but they have the RTS line (pin 4) connected to Vcc (which is also pin 4 on TT4 J2.) This port is intended for data communications equipment (DCE) which used to be for a wireline modem, but this port on the TT4 is intended for a GPS receiver - which is still a modem, of sorts, really.

When I connected the DE-9 connector on the adapter directly to my laptop (terminal equipment), with a NULL modem cable, and ran TeraTerm, it worked fine.? The adapter handshaking was satisfied because my Panasonic CF-31 Mk 5 laptop implements true RS-232 DTE, and that is why I need a NULL modem cable.? Because it is DTE to DTE connection.

But, when I connected it to the TT4, (with a DTE-DCE cable), the handshaking was not satisfied, and the data never went into the TT4 (which is the DCE).

This is because my Y cable only has TX, RX and GND. The new adapter only works because it does not support handshaking or flow control. It is thus, not a faithful implementation of RS-232.? But neither is the TT4 - until you use the proper Y cable.? This is not mentioned in the TT4 documentation.

I got mixed up because I was incorrectly assuming that we are not using proper RS-232 - just TX, RX and GND.

All along, it was not a software problem--- it was a hardware handshaking problem.

You can see my weather station at N1CTF-3 on aprs.fi?

The sensor, an Ecowitt WS90 + GW2000B, is still indoors, so you are seeing higher than normal temp readings.

Thanks again,

John N1CTF------

Here is what I have learned so far:
?? At the end of the packet is a code that appears to relate to the weather station (unit) in use.? When you set the TT4 to PEET, it append TU2K.
?? There is at least 1 station I found anywhere near me that reported as APTT4 and with TU2K.? They did have data showing, so it "is possible".
So, I set out to try and get the same.
TT4 settings:
??? AMODE TEXT???? ABAUD 19200???????????????????????? Used to monitor TT4 output
??? BMODE PEET???? BBAUD?? 2400???????????????????????? Used send PEET formatted data to TT4
??? WPERIOD 60????????????????????????????????????????????????????? Send weather data every minute (not over the air)
??? WXPOS TRUE??????????????????????????????????????????????????? Send position with weather
??? PKTICOM is TRUE? ?? PKTOCOM is TRUE??????? So I could monitor through the serial interface
The TT4 outputs:????? :!4209.34N/08346.27W_.../...g...t...r...p...P...h..b.....TU2k
I created a valid set of data from the protocol information I quoted previously.
Send the TT4 data at 2400,n,8,1
Although sending text (a single string) didn't make sense, the specification says "characters (HEX digits)" I started there because that was the TT4 example.
?? Since this is sent as a string, I tried upper and lower case)
? ? sendln "!!00B6011601D9000527FB02A101050183004B0335000E0049"
then sent the bytes:
??? sendln $21 $21 $00 $B6 $01 $16 $01 $D9 $00 $05 $27 $FB $02 $A1 $01 $05 $01 $83 $00 $4B $03 $2F $00 $0E $00 $49
next replaced humidity digits with the dashes (as in the example)
?sendln $21 $21 $00 $B6 $01 $16 $01 $D9 $00 $05 $27 $FB $21 $21 $21 $21 $01 $83 $00 $4B $03 $2F $00 $0E $00 $49
When none of that worked, I looked up Peet Bros to see what a TU2K might be and if there was some specific output.
That pointed me to the same spec I referenced.? Since it says 40, 44, or 48 bytes, I decided to try each.
? I figured I'd go for the 44 and 40 (Already tried 48 bytes)
???? sendln "!!00B6011601D9000527FB02A101050183004B0335000E"
???? sendln "!!00B6011601D9000527FB02A101050183004B0335"
???? send $21 $21 $00 $B6 $01 $16 $01 $D9 $00 $05 $27 $FB $02 $A1 $01 $05 $01 $83 $00 $4B $03 $2F $00 $0E $0D $0A
???? send $21 $21 $00 $B6 $01 $16 $01 $D9 $00 $05 $27 $FB $02 $A1 $01 $05 $01 $83 $00 $4B $03 $2F $0D $0A
Next I tried "Packet Mode" (NOTE: TT4 manual example shows !!, not $ULTW)
??? sendln "$ULTW00B6011601D9000527FB02A101050183004B0335000E0049"
??? send $24 $55 $4C $54 $57 $00 $B6 $01 $16 $01 $D9 $00 $05 $27 $FB $02 $A1 $01 $05 $01 $83 $00 $4B $03 $2F $0D $0A
?
Nothing worked!
Giving up and going to see if I can email the one station I found.
-------
Rob Giuliano
KB8RCO

OK... So I tried encoding the "!!" in all the different StandardCharsets in Java, and still not working.

Next I will try sending it with TeraTerm like you said.

If that does not work I will test it again with my Kenwood TM-D710 siting right next to it into a dummy load and see if the TTF is sending it - just in case the network has me blocked.

Basically, a picture of small vertical line with a dot under it? (an exclamation point) doesn't really tell us anything --- we have to know what language it is in.

The same is true for a so called "Carriage Return" and "Line Feed."

The exclamation point must be converted to a number in some standardized mapping scheme, because it is, itself, not a number. A decimal number, such as the air temp in Fahrenheit, has a HEX numerical equivalent. And we know that is what the TT4 is looking for. But an exclamation point is not so universal... It represents a string of ones and zeroes, in some encoding standard. Which standard? The documentation does not tell us....

So, the next question I have is: in what "character set" do you encode an exclamation point and a CR + LF so that a TT4 sees it and knows what to do with it? It might be ASCII, or UTF-8, or UTF-16 or Unicode, just as a guess.

That would be a question for Byon. Second best would be to ask the Peet brothers - because they also know the answer to the question, or their stuff would not work on a TT4.

The Peet Data Logging format says "48 hex digits + header, carriage return and line feed", on the website you sent me, which would imply that we should send 52 characters, because a '!' is a 0x21 (in ASCII Hex) and CR is 0x0D and an LF is 0x0A. But nowhere is the number "52" actually mentioned in the documentation.

Essentially, we do not know what "character set - to - number" conversion map to use for the characters that are not numbers.

Check this web site out:

If it is Unicode, the '!' needs to be 0021. And CR+LF would be 000D 000A

This is what the TT4 instruction for the v0.72 firmware shows as an example of what it expects:
!! 005A 0011 0191 04C9 281D 0296 ---- ---- 0047 035E 0000 008B (I added the spaces)
It leaves out the CR+LF. But we know that PEET puts in the CR+LF.

So, I assume that the TT4 is looking for a CR+LF just to detect the end of the data string so it can process it.

And, as you pointed out, they clearly don't expect us to encode a number into its ASCII equivalent - or there would be more than 48 characters that would need to be sent.

I think it all comes down to this: what does a TT4 expect an exclamation point to actually look like if it were a string of ones and zeroes.

I'm pretty sure that the TT4 uses an ASCII CR + LF because that is what it uses in other parts of its software - such as the configuration utility.

So next I will try the '!' in Unicode, to see if it works, and report back shortly.

John - N1CTF

Greg,
PEET may indeed make a file, but I am not making a file, just manufacturing a ASCII string with a RPi3B running Java 11, and sending it right into the input of Serial port B. I am using the jSerialComm-2.7.0 library to send the serial data.

Thanks for that. I am actually reporting all the data to fill the PEET U-II string. It is just that it is not raining in my shop. I am however showing 11 inches of rain per year, because I putt the Ecowitt WS90 sensor under the sink faucet to test it a few months ago.

One question: The APRS-1.01 spec says DAILY RAIN and also LONG TERM rain. How long a term should I be sending in that field? Weekly, monthly, yearly.... ?

Greg,
Thanks.? I will make those changes. I am pretty sure I am actually sending the data to the TT4 on the correct pin. I built the Y cable so I can have access to both the A and B ports on the DB-9 connector; I am using the B port, and when I look at the serial port on the RPi, there are received data events when I use a NULL modem adapter between the USB Serial adapter, but no receive events when I plug straight in.

Does that sound right? I will read the actual data the TT4 send back after I send it a PEET data string and report back shortly.

Rob,
This is what I get from the RPi in ASCII mode: !!00D700670280000026BC02BF0168012C004904FD000000000D0A

But in HEX mode, it is: 21213030443730303542303238423030303032364246
3032433330313545303132323030343930353038303030303030303030443041

This is HEX + ASCII Mode: !21 !21 030 030 030 030 030 030 636 030 030 232
A41 939 030 030 030 030 232 636 B42 F46 030 232 E45 C43 030 131 434 030 030 131
030 E45 030 030 434 939 030 535 434 636 030 030 030 030 030 030 030 030 030 D44
030 A41???????????????????????? ?

开云体育

开云体育

Hi Rob,
Thanks for this!
One issue I had was that I was actually sending "\r\n" for carriage return and line feed.
I changed it to "0D0A" as you show.
However the TT4 is still not doing anything with the data. The Peet U-II? does require and CR/LF at the end.
I had been using PuTTY for a terminal program on my Windows 10 laptop I use for testing.
I will install RealTerm and see what the actual output from the RPi3B is.

This is the stream I am sending: !!0000004E0174000026B902FA03660104004904CA000000000D0A

However I am not sure what the encoding really is. Is it ASCII or UTF-8?

I think you may be right about looking at the raw HEX data with RealTerm to rule that out as a problem.

I will check that now and report back shortly.

I am reporting into the APRS system on 144.39 MHz, as N1CTF-3. And I am using aprs.fi to check to? see if it is actually working. It may be working, and it is just not propagating through the network.

Do you have a way of looking at the data stream that I am actually putting into the system?

Thanks!,

John

Looking at the TT4 manual example, all values are sent in hex, except the line identifier (!! for logger data).??
The total length would be 54 Bytes (includes 2 bytes for identifier, and 2 bytes for end of line (0x0D 0x0A)
I suggest that you try sending the exact data from the manual to see if that actually sends.??
? ?Then you can manipulate the sensor data with real data.

So have your script should send:?
? ? ?!!005A0011019104C9281D0296000000000049035E0000008B0D0A
If the scripts adds the 0D0A, then don't add a second one with whatever library you may be using.
NOTE:? I filled the humidity sensor data with zeros (bold only).? And changed the DayOfYear field to today (73 is 0x0049) in bold underline.
? ? ? ? ? ? ?You may need to send the dash character (0x2D)
? ? ?!!005A0011019104C9281D02962D2D2D2D0049035E0000008B0D0A
This will equate to:
? ? ? ? ? Wind:? ?005A? ? ? ? ? ?90 / 10? ? ? ? ? ? ?or 9.0 kph
? ? Wind Dir:? ? 0011? ? ? ? ? 17 degrees
? Out Temp:? ? 0191? ? ? ? ? ?401 / 10? ? ? ? ? ?or 40.1 F
? ? ? Rain LT:? ? 04C9? ? ? ? ? 1225 / 100? ? ? or 12.25 inches
?Barometer:? ? ?281D? ? ? ? ?10269 / 10? ? ? or 1026.9 mbar
? ? ?In Temp:? ? ?0296? ? ? ? ? 662 / 10? ? ? ? ? or 66.2 F
Out Humid:? ? ? -? ?-? ? ? ? ? ? ?
? ?In Humid:? ? ? -? ?-? ? ? ? ? ? ?
DayOfYear:? ? ? 0049? ? ? ? ? ?73 day of this year
? Time(min):? ? ?035E? ? ? ? ? ?862 minutes since midnight? ?14:22 (or 2:44 pm)
? ? ?Rain ST:? ? ? 0000? ? ? ? ? ?0 inches
? Wind Avg:? ? ? ?008B? ? ? ? ? 139 / 10 or 13.9 kph
I'd suggest you at least get the DayOfYear to match today, and the time should be close, but not future.

If you post an example sentence form your script, we could help troubleshoot it.

-------
Rob Giuliano
KB8RCO

On Tue, Mar 14, 2023 at 12:46 AM, John - N1CTF wrote:

any suggestions?’

Since you are sending the data via your own code a?few of things come to mind when dealing with serial data:
1. Line ending.
? ? Does the PEET send the data with 0x0A (<LF>), 0xD (<CR>),? neither, or both?
? ? Other possibilities (although much less likely) are: 0x04 (<ETX>), 0x17 <ETB>, or 0x0C (<FF>) => not used in any grouping
? ? Even less popular would be: 0x1C (File Separator), 0x1D (Group Separator), or 0x1E (Unit separator)
2. Spaces
? ? Although most terminal programs add spaces between bytes or groups of bytes to for received data, the TT4 may not like them in the data they receive.
3. Endian
? ? Bit/Byte order can be a major issue with serial data transmission.

Can you post a sample string of data that you sent to the TT4?
I don't have a PEET device, but do have a couple of TT4 devices and could try your data format.
If you know someone who does, or have sample data from a working message (something the TT4 accepted and transmitted from an actual PEET device), that would be a big help.
Best to use a terminal program that will show the data in HEX (RealTerm for example).

-------
Rob Giuliano
KB8RCO

Hello and thanks for your responses. My apologies for taking so long to respond. I was out of town. I have written an interface in Java to the Ecowitt GW2000B / WS90 weather station and can pull off all its data over the LAN very nicely.

As for feeding data to the TY4. I am using a Prolific USB to RS232 interface dongle and I can generate what looks to me like a perfect Peet data logger sentence when looking at the Prolific device on my PC using a terminal program.?

the problem is that the TT4 will not do anything with the data. I am sending it at 2400 baud 8N1. The ABAUD is 2400 and the AMODE is PEET.?

it appears there is something I am encoding wrong. The levels are good. Not sure if I should be using UTF8??

any suggestions?’

?