|
Hello. The Lakes Region Repeater Assoc. in NH has an MTT4 that I am trying to get to do all the above. Attached are the current settings. The goal is / was to use proportional pathing (PPATHING is TRUE) so the weather report would go out local (no path) most of the time but still show on maps as an "L" digipeater. (Limited, no msg, no iGate). The other Posit, Beacon, Message would follow suit if I read the manual correctly. " Set to enable proportional pathing on sent packets. For each packet type (position,
beacon, telemetry, weather), every other transmission will be sent direct, with no
digipeater path requested. Every other remaining is sent with PATH1 only. Every fourth
is sent via PATH1, PATH2, and every eighth is sent via PATH1, PATH2+1. PATH2 is
assumed to be an n-N callsign, and PATH2+1 means the n and N are both
incremented. So a PATH2 of SS2-2 would be sent as SS3-3 every eighth transmission.
Note PPATHING does not apply to packet sent from received serial." My settings:
| PATH1 |
? |
| PATH2 |
WIDE2-1 |
| PATH3 |
? |
I thought from above, that transmissions would have a path of WIDE2-1 every fourth transmission, WIDE3-2 (or WIDE2-2) every eighth, and be direct all the others. If you look at the APRS.fi raw data for W1BST, this is NOT happening.
But, Hey, almost EVERY packet is getting to the APRSIS.
Weather Station Issue: We have an Ultimeter 100 (Peet Brothers) weather station connected. Set to Data Logger Mode (Station sends current data to MTT4 about twice a second.)
Since we beacon position and NEVER move the unit, I was trying to prevent the icon on APRS.fi from being a WX symbol. It appears to be hard coded that way if WXPOS is TRUE. (PPERIOD is 3599) as per the APRS Spec 1.01pg62 (i'm still learning)
If WXPOS is FALSE, the following is transmitted from the MTT4:???? 2021-08-18 14:00:43 EDT: >APTT4,qAR,:_........c...s...g...t...r...p...P...h..b.....TU2k [Unsupported weather format]
If WXPOS is TRUE, the following is transmitted from the MTT4: ???? 2021-08-18 17:34:46 EDT: >APTT4,qAR,:!4341.89N/07109.20W_.../...g...t...r...p...P...h..b.....TU2k
??? Power cycling the MTT4 then will get it to relay the weather station:???? 2021-08-18 23:39:53 EDT: >APTT4,qAR,:!4341.89N/07109.20W_266/002g002t072r001p000P001h..b.....TU2k
???? I am finding I need to power cycle every time, after I do a softrst. Just quitting cmd mode doesn't get the MTT4 and weather station talking correctly.
Beacon Issue:
I set BText originally to "HamFest 28 Aug 8a-2p see www.W1BST.ORG 4 detail"
I expected to see BEACON for destination in the packet. What was transmitted was:
???? 2021-08-18 14:00:44 EDT: >APTT4,qAR,:HamFest?28?Aug?8am-2pm?See?www.W1BST.0RG?details [Unsupported packet format]
I am assuming that is because there is no "APRS Data Type Identifier" in the data field
I tried ":", then ">". Would "{" be better?
Message Issue: (Messages, Bulletins and Announcements)
How do you send a message with the MTT4 set up as a digipeater? I guess it really is more like trying to sending Bulletins or Announcements.We would like to announce our local club HamFest coming up. I used the BTEXT & BPERIOD for this; but was hoping there is a better way.
Hope I provided enough information to be useful.
I am very new to APRS. I did find a and looked at addendums 1.1 and 1.2 on the APRS.org site. Is there a better PDF of the spec to be using?
/73 Paul
|
I have made some progress...
Path1 cannot be empty (null). Just putting anything in there caused expected behavior to happen in Proportional Pathing.
Beacon Text: Beacon a message, bulletin or announcement; I had to add the ":BLNx???? :" address block. Not many characters after that are left.
Weather is still an issue. The MTT4 does not like to stay in contact with the PEET Brothers output.
Even with power cycling the weather w/ position packet doesn't like to stay connected.
2021-08-23 10:40:49 EDT: >APTT4,qAR,:!4341.89N/07109.20W_.../...g003t...r...p...P000h..b.....TU2k
If I try to send a weather w/o position, APRS.fi complains that it doesn't support the weather format.
2021-08-22 14:11:23 EDT: >APTT4,qAR,:_........c...s...g...t...r...p...P...h..b.....TU2k [Unsupported weather format]
Neither of the above have data, but only the one is 'accepted'.
The Ultimeter 100 in data logger mode feds this into the MTT4:
!!0059000702A0060B----------------00E9032F00010027
But at about 2 per second. I don't want to take down the local network. :o? But it is an acceptable packet. Didn't have time to really test it yesterday to see if the weather was being decoded by APRS.fi or local radios.
In Packet Mode the follow is outputted every five minutes:
$ULTW00B2000402A2060C----000086A00001----00E9034300020032
APRS.fi accepts this fine too.
In both cases, I put port B to TEXT mode. But it appeared that received packets were being sent to the Ultimeter and the ultimeter was in full duplex. Ergo, all received packets were being sent again as UI packets. OOPS. I see DeafText now and think that might be better for port B.
Two questions still remain; why doesn't Weather without position work and why does the TT4 not stay in communication with the PEET Data Logger Mode?
//AC1DW
|
sent over email, but did not seem to post.
I don't know much about sending weather information using the Byonics products, so can't help there.
BUT ...
Looking through the configuration file? you attached to the original message for anything obvious that I could spot, there are a lot of other settings that should be investigated:
The ALIAS setting are used for what the TT4 will DIGI
????ALIAS1 TEMP
????ALIAS2 WIDE
????ALIAS3 SS2
These appear to be some kind of default, especially SS2?
??? SS is typically an abbreviation for your 2 character state code and the 2 would limit the TT4
???????? to DIGI only paths with first element of 2 (SS2-2 and SS2-1).
???????? In your case, it appears it would be NH2 (not SS2)
??? I am not a fan of TEMP, but it may be in use in your area.
??? I prefer to limit my ALIASes (as you have done on the SS) by giving them a number.
??????? The down side to this is that it requires more ALIASes to cover a setting.
??????? PREEMPT TRUE can help with that.
You should check with any local APRS groups on what is used in your area.
My recommendation would be:
????ALIAS1 TEMP2
????ALIAS2 WIDE2
????ALIAS3 NH2
??? PREEMPT TRUE
That is if you want to DIGI TEMP paths.? This limits them to 2 settings, but PREEMPT means it will DIGI the packet if TEMP2, WIDE2, or NH2 are anywhere in the path.
?
As you stated, PATH elements need to be used in order.? If you only use one path element, it needs to be in PATH1.
|
I don't know much about sending weather information using the Byonics products, so can't help there.
BUT ... Looking through the configuration file? you attached to the original message for anything obvious that I could spot, there are a lot of other settings that should be investigated: The ALIAS setting are used for what the TT4 will DIGI ????ALIAS1 TEMP ????ALIAS2 WIDE
????ALIAS3 SS2 These appear to be some kind of default, especially SS2? ??? SS is typically an abbreviation for your 2 character state code and the 2 would limit the TT4 ???????? to DIGI only paths with first element of 2 (SS2-2 and SS2-1).
???????? In your case, it appears it would be NH2 (not SS2) ??? I am not a fan of TEMP, but it may be in use in your area. ??? I prefer to limit my ALIASes (as you have done on the SS) by giving them a number. ??????? The down side to this is that it requires more ALIASes to cover a setting. ??????? PREEMPT TRUE can help with that. You should check with any local APRS groups on what is used in your area.
My recommendation would be: ????ALIAS1 TEMP2 ????ALIAS2 WIDE2
????ALIAS3 NH2 ??? PREEMPT TRUE
That is if you want to DIGI TEMP paths.? This limits them to 2 settings, but PREEMPT means it will DIGI the packet if TEMP2, WIDE2, or NH2 are anywhere in the path.
As you stated, PATH elements need to be used in order.? If you only use one path element, it needs to be in PATH1.
On Monday, August 23, 2021, 11:00:29 AM EDT, AC1DW <kc1hep@...> wrote:
I have made some progress...
Path1 cannot be empty (null). Just putting anything in there caused expected behavior to happen in Proportional Pathing.
Beacon Text: Beacon a message, bulletin or announcement; I had to add the ":BLNx???? :" address block. Not many characters after that are left.
Weather is still an issue. The MTT4 does not like to stay in contact with the PEET Brothers output.
Even with power cycling the weather w/ position packet doesn't like to stay connected.
2021-08-23 10:40:49 EDT: >APTT4,qAR,:!4341.89N/07109.20W_.../...g003t...r...p...P000h..b.....TU2k
If I try to send a weather w/o position, APRS.fi complains that it doesn't support the weather format.
2021-08-22 14:11:23 EDT: >APTT4,qAR,:_........c...s...g...t...r...p...P...h..b.....TU2k [Unsupported weather format]
Neither of the above have data, but only the one is 'accepted'.
The Ultimeter 100 in data logger mode feds this into the MTT4:
!!0059000702A0060B----------------00E9032F00010027
But at about 2 per second. I don't want to take down the local network. :o? But it is an acceptable packet. Didn't have time to really test it yesterday to see if the weather was being decoded by APRS.fi or local radios.
In Packet Mode the follow is outputted every five minutes:
$ULTW00B2000402A2060C----000086A00001----00E9034300020032
APRS.fi accepts this fine too.
In both cases, I put port B to TEXT mode. But it appeared that received packets were being sent to the Ultimeter and the ultimeter was in full duplex. Ergo, all received packets were being sent again as UI packets. OOPS. I see DeafText now and think that might be better for port B.
Two questions still remain; why doesn't Weather without position work and why does the TT4 not stay in communication with the PEET Data Logger Mode?
//AC1DW
|
Thank you Rob.
There seems to be issues with TT4 and PEET Brothers telemetry.
I do have the weather packets going out now without the position. The system seems to ok with the format once time and date is inserted. The TT4 doesn't decode the day correctly though. They are showing a day behind. (8/22 instead of 8/23). Guess not a big deal since time is dropped in those packets at the iGate. Funny though, is that my time in the packet is more correct than what ever system is putting the time stamp on the data.
Thank you for the PREEMPT explaination. The online information and manual wasn't clear enough for me to try it. I will be using.
Yes, I did finally see/realize the SS should be NH.
If I use PREEMPT and an alias1 of NH, would I digipeat any NHn-N and decrement correctly?
Would a NHn* NOT be digipeated?
I have changed my alias-list to:
alias1 is NH (We want to be sure NH message get around the mountains.)
alias2 is WIDE2
and set PREEMPT is TRUE.
Thank you for chiming in.
AC1DW
|
You have a TEXT port and a PEET port, so no GPS port.
I am curious how the MTT4BT gets a time and date with no GPS attached?
As far as I can tell, there is no RTC and no means of setting the time. The timing appears to be either from delta time between TX, or time from the GPS.
I cannot say I've ever investigated this, but I see 3 scenarios: 1. No GPS.? Assume poackets sent without timestamp 2. With GPS -> GPS provide time 3. Start with GPS attached, then remove GP.?
??? Does the MTT4BT keep time from last acquired information - that would likely get out of date fairly quickly.
Robert Giuliano KB8RCO
|
Some time back I corresponded with a fellow in the aprs-is (group/provider...?) system when I was formatting wx packets to be posted via the net.? I recall something about the aprs-is system ignoring times in packets and adding a real timestamp when packets arrived -- something about them not trusting any other times given to them, since they would often be bogus (or just off, as in the case of a battery-backed rtc or such).? Makes sense to me.? I was sending incorrect times in packets when I was first playing around, those incorrect timestamps were ignored by the system.? I would guess that the radio side of aprs would do the same thing as those packets get added to the system.
----- Original message -----
Subject: Re: [TinyTrak] MTT4BT Digipeater, weather station, Beacon, and Message issues....
Date: Tuesday, August 24, 2021 4:27 PM
You have a TEXT port and a PEET port, so no GPS port.
I am curious how the MTT4BT gets a time and date with no GPS attached?
As far as I can tell, there is no RTC and no means of setting the time.
The timing appears to be either from delta time between TX, or time from the GPS.
I cannot say I've ever investigated this, but I see 3 scenarios:
1. No GPS.? Assume poackets sent without timestamp
2. With GPS -> GPS provide time
3. Start with GPS attached, then remove GP.?
??? Does the MTT4BT keep time from last acquired information - that would likely get out of date fairly quickly.
Robert Giuliano
KB8RCO
|
Gil, that is what I read too.?
Rob, the PEET data has a date (MM/dd) and time (hh:mm) in the packet it sends (data or packet modes).
The TT4 is decoding like this is a leap year. It is a day behind now. Don't know what January would look like though.??
I'm going to do a reset to factory defaults and start from there. I haven't been able to recreate some of the anomalies I've observed. One being; when both ports were in TEXT mode, the decoded received packets were being transmitted as "UI" input.?
2021-08-22 13:34:02
>APTT4,WIDE2-1,NH4-4,qAR,:W1IMD>APN391:!4350.15NS07049.05W#PHG3464
|
Any system that does not have an active GPS should not use an APRS
protocol that includes a time stamp.
There should be a non-time-stamp version of every packet type. (I hope)
Bob, WB4APR
toggle quoted message
Show quoted text
On Wed, Aug 25, 2021 at 2:21 AM Gil Smith <tinytrak@...> wrote:
Some time back I corresponded with a fellow in the aprs-is (group/provider...?) system when I was formatting wx packets to be posted via the net. I recall something about the aprs-is system ignoring times in packets and adding a real timestamp when packets arrived -- something about them not trusting any other times given to them, since they would often be bogus (or just off, as in the case of a battery-backed rtc or such). Makes sense to me. I was sending incorrect times in packets when I was first playing around, those incorrect timestamps were ignored by the system. I would guess that the radio side of aprs would do the same thing as those packets get added to the system.
----- Original message -----
From: "Rob Giuliano via groups.io" <kb8rco@...>
To: "[email protected]" <[email protected]>
Subject: Re: [TinyTrak] MTT4BT Digipeater, weather station, Beacon, and Message issues....
Date: Tuesday, August 24, 2021 4:27 PM
You have a TEXT port and a PEET port, so no GPS port.
I am curious how the MTT4BT gets a time and date with no GPS attached?
As far as I can tell, there is no RTC and no means of setting the time.
The timing appears to be either from delta time between TX, or time from the GPS.
I cannot say I've ever investigated this, but I see 3 scenarios:
1. No GPS. Assume poackets sent without timestamp
2. With GPS -> GPS provide time
3. Start with GPS attached, then remove GP.
Does the MTT4BT keep time from last acquired information - that would likely get out of date fairly quickly.
Robert Giuliano
KB8RCO
|
The APRS weather without location seems to require a time stamp.?
Looking at raw data on aprs.fi for w1bst; it appears that way.?
|
There is provision for a local time stamp tht indicates it is not real-time
but CPU clock time. I instead of ending with DDHHMMz it ends (I think)
with HHMMSSh from the last time the CPU was started. THe "h"
indicates it is CPU time. (Alll this from memory since I dont have
the energy to look it up).
In any case the original post was correct in that time stamps should
usually be ignored in systematic use and the TIME OF RECEPIT
should be used for accuracy.
Bob, WB4APR (forgetting a lot these days)...
toggle quoted message
Show quoted text
On Wed, Aug 25, 2021 at 11:46 AM AC1DW <KC1HEP@...> wrote:
The APRS weather without location seems to require a time stamp.
Looking at raw data on aprs.fi for w1bst; it appears that way.
|
Did you get this problem resolved? Mine seems to digi ok but it will not read the weather station.?
This is a before and after. First two lines were using a TT3. Second were using the TT4.
KJ7AZ-3>APTW14,WIDE2-2,WIDE2-1,qAS,KJ7AZ-10:!3359.51N/10549.42W_217/000g000t072r000p000P000h..b.....tU2k
KJ7AZ-3>APTW14,WIDE2-2,WIDE2-1,qAS,KJ7AZ-10:!3359.51N/10549.42W_217/000g000t073r000p000P000h..b.....tU2k
KJ7AZ-3>APTT4,WIDE2-1,qAS,KJ7AZ-10:!3359.49N/10549.42W_.../...g...t...r...p...P...h..b.....TU2k
KJ7AZ-3>APTT4,WIDE2-1,qAS,KJ7AZ-10:!3359.49N/10549.42W_.../...g...t...r...p...P...h..b.....TU2k
If yours is fixed post your settings. Thanks
KJ7AZ
|
No. We still have some issues.
When it is working, it works fine. When it isn't, it is hard to get re-connected.
Latest data point.... We also have / had the optional indoor temperature sensor attached. That seems to aggravate the TT4 decode process. With the optional temperature sensor disconnected it tends to work better.
Our best luck so far; Run the PEET Bros. in Data Logger Mode. We have had the weather station stop sending data for some reason. So cycling modes between Data Logger and Packet and back to Data Logger seemed to restore it.
I have also noticed that the data from the weather station is correct but the TT4 is now a day behind. Almost as if it thinks it is a leap year. Not a big issue I guess since the date/time is dropped from? reports sent by stations.
There also seems to be an "ideal sequence" to get it running, but we haven't recorded it yet. To many cooks in the kitchen?
Getting the data stream from the weather station running first; then power cycle the TT4 second appears the best approach (IIRC)
It may also take an hour before data is correct because the rain report is "last hour" "last 24 hours" "Since Midnight"; I'm guessing it needs to collect the rain report. that is just guessing at this point. We get frustrated, go home, and then check aprs.fi later AND VIOLA - it is putting out data.
/AC1DW
|
OK, Thank You. I got the DIGI up and running without issue. May have to just put the TT3 back online because the weather is more important. Will keep working with it here. Thanks again.
|
Had to surrender and put the WXTrack back online. I had it working great as a digi but it just wont function for WX with the Peet. I'll keep watching to see if anyone gets lucky or maybe a firmware update or something.
|
Here is something I noticed which may or may not be of use. This concerns Abaud and Bbaud. Setting Abaud and Bbaud to 2400 causes the TT4 unit to transmit a continuous string of hexadecimal weather packets. Even though the TNC is set to 2400 you still need to use 19200 to log into it TeraTerm. I'm assuming that's the USB cables doing BUT..... Logging into the TT3 using the same cable requires 2400 baud. Checking the Abaud and Bbaud after logging into the TT4 still shows both set to 2400. What I'm wondering is if there may be a flaw of some kind that causes the TT4 to switch baud rates internally without changing the command. The Peet equipment sends data at 2400 baud. Maybe the TT4 just isn't on the right baud rate or bit rate. 2400, 8, 1 null... Finally, the Peet weather stations have a packet mode. I might take a try and see if something can be done with that. Rather than sending data every second it sends every 5 minutes. Packet mode is a longer packet but who knows, might get lucky.
|
The MTT4BT starts in a bootloader that communicates at 19200 baud (now on either port as of recent firmware).
The ABAUD and BBAUD values are used to set the port speed after the bootloader (after finishing the "Hit Escape 3 times message" and going into the normal "run mode").? Everyone who has used any interface successfully at rates less than 19200 can confirm this is working, as has been since initial TT4 versions.
There is not much information about the Peet weather station interface.? The TT4 firmware manual does not say whether the information the TT4 decodes is the direct serial or the 5-minute packet mode. From some other posts, there is a reference to "Peet $ULTW 52 character sentence".? I place a good bet that, that is the decoded format.
? from your previous post, you show? $ULTW00B2000402A2060C----000086A00001----00E9034300020032
Putting the 2 threads together, it sounds to me like you want the Peet to be in Packet Mode.
?
Robert Giuliano KB8RCO
On Saturday, September 25, 2021, 11:35:21 PM EDT, KJ7AZ <tim81499@...> wrote:
[Edited Message Follows]
Here is something I noticed which may or may not be of use. This concerns Abaud and Bbaud. Setting Abaud and Bbaud to 2400 causes the TT4 unit to transmit a continuous string of hexadecimal weather packets. Even though the TNC is set to 2400 you still need to use 19200 to log into it TeraTerm. I'm assuming that's the USB cables doing BUT..... Logging into the TT3 using the same cable requires 2400 baud. Checking the Abaud and Bbaud after logging into the TT4 still shows both set to 2400. What I'm wondering is if there may be a flaw of some kind that causes the TT4 to switch baud rates internally without changing the command. The Peet equipment sends data at 2400 baud. Maybe the TT4 just isn't on the right baud rate or bit rate. 2400, 8, 1 null... Finally, the Peet weather stations have a packet mode. I might take a try and see if something can be done with that. Rather than sending data every second it sends every 5 minutes. Packet mode is a longer packet but who knows, might get lucky.
|
I'm agreeing on packet mode. I'll try that later today. Cross your fingers, knock on wood, throw a penny over your shoulder.
KJ7AZ
|
this did not work. TT4 works great as a digi but no luck at all on PEET weather. Going to do it the easy way. I'll use the TT4 for the digi and the TT3 for weather. Seems to be the only way. If someone comes up with a way to make the Peet and TT4 work properly let us know.
Thanks
KJ7AZ
|
Tim ?Sounds like you are wanting to do what I have been working on to replace the 9 Mile node. ?Lack of time. ?I do use the TT4 as a modem between the radio and computer for I-Gate and have a Peet 2100 on the other port. Been working like that for several years. As soon as I get the node ready let you know.? ?Still have the same e-mail address. ?74 ?Mike - N7ZEF
On Sat, 25 Sep 2021 07:51:45 -0600, KJ7AZ <tim81499@...> wrote:
OK, Thank You. I got the DIGI up and running without issue. May have to just put the TT3 back online because the weather is more important. Will keep working with it here. Thanks again.
-- Using Opera's mail client:
|
AC1DW