Open OH2LAK opened 1 year ago
Hello,
it's a better idea to contact me directly instead of opening a github ticket. But since you made this topic public, please let me first point out (for all other readers in the world ;) that fixed stations are recommended to use a beacon interval of 30-60 minutes.
I see your booted message at findu.com http://findu.com/: http://findu.com/cgi-bin/raw.cgi?call=OH2LAK-15&time=1
-> Per se, the aprs-is connection works.
In the web interface you may see that he sends this beacon to aprsis. (This is the part "aprsis_status = "OK, toAPRSIS: " + s_data;");
At http://findu.com/cgi-bin/errors.cgi I don't see your callsign. That's good.
You wrote, that RF to aprsis works correctly. Your own becacon and received-packets-over-lora go the same way: via the function send_to_aprsis(). Thus it's not really understandable, that your own beacon does not work, but the stuff you gate from RF works.
So my first question is: did you try another aprs server (i.e. euro.aprs2.net http://euro.aprs2.net/)? I ask because I never used igates.aprs.fi http://igates.aprs.fi/ and know anybody who used it. Perhaps there's a compatibility issue.
My next question (and I think it's the more important one): did you check your aprs symbol table / symbol code settings?
APRS symbol code and APRS symbol-table is really confusing - but these words are defined by the APRS standard.
Let's look at a working beacon: DB0LY-10>APLOX1,Q,qAU,DB0LY:!5312.72NL01316.47E&LoRa-APRS iGATE 433.775MHz Firmware SQ9MDD/DL9SAU/DL3EL ..and the code in prepareAPRSFrame(), that builds the frame above, is:
outString += (may_add_dao_extension ? aprsLatPresetDAO : aprsLatPreset);
outString += aprsSymbolTable;
outString += (may_add_dao_extension ? aprsLonPresetDAO : aprsLonPreset);
outString += aprsSymbol;
-> Ok, first is symbolTable, second is symbol. In the case of db0ly: "L" is symbolTable, and "&" is symbol.
In your settings I read: | "aprs_s_table":"&",
"aprs_symbol":"L",
-> _____ "&" is symbolTable, and "L" is symbol in your setting.
I think this is the cause the packets are dropped.
Read more about aprs symbols at http://www.aprs.org/symbols/symbols-new.txt There you also find the definition of "L& - Lora Igate"
Compare it in that document with "/[ = Human" http://findu.com/cgi-bin/raw.cgi?call=DL9SAU-12&time=1 20231025100509,DL9SAU-12>APLOX1-1,qAU,DB0FRI-10:=5330.57N/00733.40E[229/000/145.500MHz d023/Thomas D23. LoRa 70cm; KISS-Test !W75! _____^SymTable ^SymCode
Btw, it is not a bug not prevent a user from configuring not-yet defined icons (as long as they are not reserved characters due to the spec). Else software would need to be recompiled if in the future new icons are invented and become valid.
In your settings we see a (correct) password. It would be wise to change it, but it's unchangeable by design. You're lost :-S
vy 73,
Am 25.10.2023 um 09:38 schrieb oh2lak @.***>:
Using the TTGO-T-Beam with @dl9sau fork firmware, for some reason the location beacon of the TTGO-T-Beam LoRa iGate itself does not go to APRS-IS I can verify that connection to APRS-IS is functioning as packets do reach IS by observing e.g. https://aprs.fi/?c=raw&call=OH2LAK-15 and the igate is relaying from LoRa to APRS-IS successfully. The specific settings which should make the own beacon go to APRS-IS is enabled. Here's a list of variety of parameters I think have something to do with this topic; { "tx_aprsis_bc":true, "tx_aprsis_sm":true, "aprs_callsign":"OH2LAK-15", "aprs_relay_path":"WIDE1-1", "aprs_s_table":"&", "aprs_symbol":"L", "aprs_objnam":"", "aprs_comment":"Lora Digi/iGate 433.775", "aprs_lat_p":"60-11.4299N", "aprs_lon_p":"024-45.7920E", "pos_amb":0, "aprs_blist":"", "aprs_fb_interv":300, "aprs_fixed_beac":true, "aprsis_en":true, "aprsis_srv_h":"igates.aprs.fi", "aprsis_srv_p":14580, "aprsis_fltr":"", "aprsis_call":"", [..] "aprsis_2rf":1, } — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Hi and thanks for your reply Thomas!
The point of opening an issue was exactly to give the topic some publicity so maybe someone else struggling with the same issue gets help and guidance at the same time. It is not to point fingers at anyone.
First of all, congrats on the very feature-rich code. The web UI is really superior. It is very useful for configuration, debugging and upgrading remote-mounted fixed stations like igates and I think the KISS interface to hook the LORA-TRX to APRX or some other platform is a very good feature.
I figured out the root cause of the igate own beacons not going to APRS-IS and I think it is a bug: The own beacon will not go to APRS-IS unless the LORA transmitter is enabled, 'lora_tx_en:true'. These two "ports" should be separated and not dependent on each other.
In our case, LORA igates will be mostly RX-only so the LORA transmitter will be disabled as it also would require a specific license for such unmanned stations, even being low-power LORA. We already have some LORA RX-iGates but they are apparently running some other firmware as they do beacon to APRS-IS even with LORA TX disabled.
The reason for using the specific igates.aprs.fi host was to investigate the connection on a lower level and do traffic sniffing but I never made it that far and it looks unnecessary now as well.
APRS-passcode is not really a password and offers no protection, and it cannot be changed as it is derived from the callsign.
73, Erik OH2LAK APRS.fi
On Wed, 25 Oct 2023 at 19:39, Thomas Osterried @.***> wrote:
Hello,
it's a better idea to contact me directly instead of opening a github ticket. But since you made this topic public, please let me first point out (for all other readers in the world ;) that fixed stations are recommended to use a beacon interval of 30-60 minutes.
I see your booted message at findu.com http://findu.com/: http://findu.com/cgi-bin/raw.cgi?call=OH2LAK-15&time=1
-> Per se, the aprs-is connection works.
In the web interface you may see that he sends this beacon to aprsis. (This is the part "aprsis_status = "OK, toAPRSIS: " + s_data;");
At http://findu.com/cgi-bin/errors.cgi I don't see your callsign. That's good.
You wrote, that RF to aprsis works correctly. Your own becacon and received-packets-over-lora go the same way: via the function send_to_aprsis(). Thus it's not really understandable, that your own beacon does not work, but the stuff you gate from RF works.
So my first question is: did you try another aprs server (i.e. euro.aprs2.net < http://euro.aprs2.net/>)? I ask because I never used igates.aprs.fi http://igates.aprs.fi/ and know anybody who used it. Perhaps there's a compatibility issue.
My next question (and I think it's the more important one): did you check your aprs symbol table / symbol code settings?
APRS symbol code and APRS symbol-table is really confusing - but these words are defined by the APRS standard.
Let's look at a working beacon: DB0LY-10>APLOX1,Q,qAU,DB0LY:!5312.72NL01316.47E&LoRa-APRS iGATE 433.775MHz Firmware SQ9MDD/DL9SAU/DL3EL ..and the code in prepareAPRSFrame(), that builds the frame above, is:
outString += (may_add_dao_extension ? aprsLatPresetDAO : aprsLatPreset); outString += aprsSymbolTable; outString += (may_add_dao_extension ? aprsLonPresetDAO : aprsLonPreset); outString += aprsSymbol;
-> Ok, first is symbolTable, second is symbol. In the case of db0ly: "L" is symbolTable, and "&" is symbol.
In your settings I read: | "aprs_s_table":"&",
"aprs_symbol":"L",
-> _____ "&" is symbolTable, and "L" is symbol in your setting.
I think this is the cause the packets are dropped.
Read more about aprs symbols at http://www.aprs.org/symbols/symbols-new.txt There you also find the definition of "L& - Lora Igate"
Compare it in that document with "/[ = Human" http://findu.com/cgi-bin/raw.cgi?call=DL9SAU-12&time=1 20231025100509,DL9SAU-12>APLOX1-1,qAU,DB0FRI-10:=5330.57N/00733.40E[229/000/145.500MHz d023/Thomas D23. LoRa 70cm; KISS-Test !W75! _____^SymTable ^SymCode
Btw, it is not a bug not prevent a user from configuring not-yet defined icons (as long as they are not reserved characters due to the spec). Else software would need to be recompiled if in the future new icons are invented and become valid.
In your settings we see a (correct) password. It would be wise to change it, but it's unchangeable by design. You're lost :-S
vy 73,
- Thomas dl9sau
Am 25.10.2023 um 09:38 schrieb oh2lak @.***>:
Using the TTGO-T-Beam with @dl9sau fork firmware, for some reason the location beacon of the TTGO-T-Beam LoRa iGate itself does not go to APRS-IS I can verify that connection to APRS-IS is functioning as packets do reach IS by observing e.g. https://aprs.fi/?c=raw&call=OH2LAK-15 and the igate is relaying from LoRa to APRS-IS successfully. The specific settings which should make the own beacon go to APRS-IS is enabled. Here's a list of variety of parameters I think have something to do with this topic; { "tx_aprsis_bc":true, "tx_aprsis_sm":true, "aprs_callsign":"OH2LAK-15", "aprs_relay_path":"WIDE1-1", "aprs_s_table":"&", "aprs_symbol":"L", "aprs_objnam":"", "aprs_comment":"Lora Digi/iGate 433.775", "aprs_lat_p":"60-11.4299N", "aprs_lon_p":"024-45.7920E", "pos_amb":0, "aprs_blist":"", "aprs_fb_interv":300, "aprs_fixed_beac":true, "aprsis_en":true, "aprsis_srv_h":"igates.aprs.fi", "aprsis_srv_p":14580, "aprsis_fltr":"", "aprsis_call":"", [..] "aprsis_2rf":1, } — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/SQ9MDD/TTGO-T-Beam-LoRa-APRS/issues/107#issuecomment-1779660950, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEJADXZ4F3WVMQTVVLUPZTYBE6D7AVCNFSM6AAAAAA6O4VANCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZZGY3DAOJVGA . You are receiving this because you authored the thread.Message ID: @.***>
Hello Erik,
I figured out the root cause of the igate own beacons not going to APRS-IS and I think it is a bug: The own beacon will not go to APRS-IS unless the LORA transmitter is enabled, 'lora_tx_en:true'. These two "ports" should be separated and not dependent on each other.
I'll check this. It must be a new bug, because:
In our case, LORA igates will be mostly RX-only so the LORA transmitter
..in our case, LORA igates will be mostly RX-only.
will be disabled as it also would require a specific license for such unmanned stations, even being low-power LORA. We already have some LORA
Also here.
If you have 10 igates nearby and every igate xmits every 10min his bacon, we have a beacon every minute on the air. If a transmission lasts 5 seconds, we loose 1/12 airtime.
RX-iGates but they are apparently running some other firmware as they do beacon to APRS-IS even with LORA TX disabled.
I assume the regression came with this commit in Apr 2023 (unfortunately, no one reported it - but even here igates should be rx-only):
https://github.com/dl9sau/TTGO-T-Beam-LoRa-APRS/commit/a00555f9cc8111e0caeff9db4a7f739c83c53d6e
Line 515 / 513:
Please remove the words "lora_tx_enabled &&" and recompile.
This will result in a block:
// fixed beacon, or if smartbeaconing with lost gps fix (but had at least one gps fix). // smartbeaconing also ensures correct next_fixed_beacon time if (!dont_send_own_position_packets && millis() >= next_fixed_beacon && (fixed_beacon_enabled || ((!gps_state || !gps_isValid) && t_last_smart_beacon_sent && t_last_smart_beacon_sent + sb_max_interval < millis()) ) ) { nextTX = sb_max_interval;
I'll also change this one to the old behavior:
Sendpacket also checks if tx is disabled. And loraSend as last resort also do. I did this change because I thought it would be a good idea to not jump into functions that will do nothing - and I've overseen the case that there's a state where it really does something (sending to aprsis). I think I looked at the display, saw the tx message, but I had disabled TX in configuration, and thought, it's not good to say we are TXing but we won't.
Please give me feedback on this.
vy 73,
Hello Erik,
please test my fix, see commit https://github.com/dl9sau/TTGO-T-Beam-LoRa-APRS/commit/17c278c53bd86d43a138114c6948f54c43d13b71
vy 73,
Using the TTGO-T-Beam with @DL9SAU fork firmware, for some reason the location beacon of the TTGO-T-Beam LoRa iGate itself does not go to APRS-IS
I can verify that connection to APRS-IS is functioning as packets do reach IS by observing e.g. https://aprs.fi/?c=raw&call=OH2LAK-15 and the igate is relaying from LoRa to APRS-IS successfully.
The specific settings which should make the own beacon go to APRS-IS is enabled. Here's a list of variety of parameters I think have something to do with this topic;
{ "tx_aprsis_bc":true, "tx_aprsis_sm":true, "aprs_callsign":"OH2LAK-15", "aprs_relay_path":"WIDE1-1", "aprs_s_table":"&", "aprs_symbol":"L", "aprs_objnam":"", "aprs_comment":"Lora Digi/iGate 433.775", "aprs_lat_p":"60-11.4299N", "aprs_lon_p":"024-45.7920E", "pos_amb":0, "aprs_blist":"", "aprs_fb_interv":300, "aprs_fixed_beac":true, "aprsis_en":true, "aprsis_srv_h":"igates.aprs.fi", "aprsis_srv_p":14580, "aprsis_fltr":"", "aprsis_call":"", "aprsis_pw":"20397", "aprsis_2rf":1, }