nakhonthai / ESP32APRS_T-TWR

APRS Software project device support LILYGO T-TWR Plus.
GNU General Public License v3.0
117 stars 18 forks source link

APRS message in the DashBoard may exceed width of the "LAST HEARD" WebUI frame #3

Closed lyusupov closed 1 year ago

lyusupov commented 1 year ago
image



Expected behavior

It is expected that the frame width should stay within the style defined boundaries regardless the actual length of the APRS message

nakhonthai commented 1 year ago

Error in APRS packet not path or last path fail.

lyusupov commented 1 year ago

Error in APRS packet not path or last path fail.

Not necessarily.

The same source produces the APRS packets that give NO error :

image

The effect is sporadic - most packets received do not cause the ESP32APRS WebUI glitch, but some does. I would estimate 80% PASS and 20% FAIL ratio.

Another argument: the same source do not cause any issues with other APRS iGates, such as Dire Wolf

Anyway, the reason for opening this issue is: regardless of the data received - the ESP32APRS WebUI is expected to maintain the constant HTML frames width.

nakhonthai commented 1 year ago

AC7574>OGFLR:/065718h56 <<- The package has no path.

Function handle_lastHeard() in webservice.cpp not protection code.

int start_info = line.indexOf(":", 0); 
int end_ssid = line.indexOf(",", 0);
int start_dst = line.indexOf(">", 2);
int start_dstssid = line.indexOf("-", start_dst);
String path = line.substring(end_ssid + 1, start_info);
lyusupov commented 1 year ago

The package has no path.

What is wrong with an APRS message having no PATH ? https://blog.aprs.fi/2020/02/how-aprs-paths-work.html

Moreover, the aprs.glidernet.org APRS-IS server that handles the OGFLR destination is expecting that a receiver (OGN project software or a generic APRS iGate) can process no-PATH messages: https://github.com/glidernet/ogn-aprs-protocol/blob/master/aprsmsgs.txt

Read this excerpt for details: https://github.com/glidernet/ogn-aprs-protocol/blob/master/aprsmsgs.txt#L118-L125

nakhonthai commented 1 year ago

The protocol is not wrong. But my code made a mistake in not protecting this part. Resulting in incorrect display. I fixed it in version 0.2a You can test update by OTA. SETTING->SYSTEM->ABOUT->OTA Update

lyusupov commented 1 year ago

I fixed it in version 0.2a

Thank you!

V0.2 does not seem to have the "OTA Update" button that would download & install V0.2a from your site automatically. I can see no V0.2a .bin file in Releases area that I could download and install manually (with esptool or "Firmware Update" button).

image
nakhonthai commented 1 year ago

You can download direct from my server at http://www.dprns.com/ESP32/ESP32APRS_TWR.bin or OTA from device.

https://github.com/nakhonthai/ESP32APRS_T-TWR/assets/16043758/d68e66be-8420-41ed-9f93-28a09685b6e7

lyusupov commented 1 year ago

@nakhonthai

Thanks' for the tip! The OTA firmware update went smooth.

I can confirm positive effect of this commit https://github.com/nakhonthai/ESP32APRS_T-TWR/commit/964f1e38539496c31a1846a23c3072708ce74f2f

image

I no longer see an artifact specified in the issue description. Thank you for the fix!