Change OGN Tracker settings not possible

[scheuss]

1. Stratux version: v1.6r1-eu30

2. Stratux config:

   SDR

   • [ ] single
   • [X] dual

   GPS

   • [X] yes
   • [ ] no type: LILYGO T-BEAM V1.1

   AHRS

   • [X] yes
   • [ ] no

   power source: USB

   usb cable:

3. EFB app and version: (e.g., WingX Pro7 8.6.2)

   EFB platform: (e.g., iOS 9.2)

   EFB hardware: (e.g., iPad Mini 2)

4. Description of your issue:

Hello,

I have a problem with the OGN Tracker Settings. I set a Tracker Address and a Registration, then press the button ‘Configure OGN Tracker’ and restart the Stratux. After restart the Tracker Address and the Registration is from an aircraft set before update to eu30-version.

I reflashed the image v1.6r1-eu30 to the SD card. After startup of the Stratux, the OGN Tracker was already configured with the aircraft used before update to eu30-version.

It looks like an old config is saved on the TTGO T-Beam v1.1 and automatically reloaded. I can change the Tracker Address and a Registration settings, the new values are visible in the ‘stratux.conf’ file at the end of the settings page but after restart both settings are overwritten with the old values.

I tried to change these settings with an android and an iPhone device.

If I insert the old SD card with the previous version, everything works fine.

Any idea what the problem could be? Any similar problems?

stratux.log

[b3nn0]

I have had the same reported by one other person already, but unfortunately I can not reproduce it, which makes it hard to fix this, unfortunately..

[scheuss]

Are the Tracker Address and a Registration stored in a non-volatile memory in the T-Beam? At startup of the Stratux, are those values read from the T-Beam?

[b3nn0]

Yes to both. The stuff you see on stratux.conf is basically just caching of the values. I do wonder if the TBeam does receive the values at all. If you only restart the Stratux process (sudo stxrestart), are the values also reset after a couple of seconds? Is the TBeam actually transmitting the ID you try to configure before the reboot? I suspect not..

[scheuss]

Yes, after a stxrestart command (not turn off and on power) the old values are visible again. The TBeam always sending the old values. I can change Tracker Address and a Registration, confirm with ‘Configure OGN Tracker’ but on https://live.glidernet.org/ I only see the old settings.

As a test I inserted the SD card with the old V1.6r1-eu29 image. I checked on ogn if I receive the aircraft at my location -> everything OK. I changed Tracker Address and a Registration, I see the new aircraft at my location almost immediately. Works perfect. Then, I inserted the SD card with the newest eu30-firmware. After startup, I see the Tracker Address and a Registration of the latest setting with the old old eu29 image. (This setting was on the TBeam for sure, the SD card was changed) On ogn, I see the aircraft at my location as visible in the settings page. If I change then Tracker Address and a Registration I don’t get a new aircraft at my location. It looks like Stratux is not sending this new information to the TBeam.

[b3nn0]

Well, unfortunately I can not reproduce all that. Works just fine for me, so I need a bit of help here. What is interesting: Right after writing the settings, Stratux requests the current settings from OGN Tracker to verify that configuration worked. It will then update the stratux.conf/web interface with whatever it received. Apparently, this "Settings request" also didn't get through - otherwise your Settings would reset almost immediately. HOWEVER This is the same request that is done on startup, so apparently, the "settings request" seems to work initially, but fails later on.

Mind troubleshooting a bit? These are some tests that come to mind:

1. The only thing that really changed in EU030 was - beside the base operating system - a USB related boot flag I had to set. Otherwise the Bookworm kernel would crash completely when connecting a TTGO T-Motion. Could you try removing that flag again for the sake of testing? Just comment out this line from /boot/firmware/config.txt: https://github.com/b3nn0/stratux/blob/b4d0ca1f0f21778df3a42fce70c67cac29b2d96e/image/config.txt#L19
2. This is the function that sends the configuration string. Maybe you could do some trial and error there: https://github.com/b3nn0/stratux/blob/b4d0ca1f0f21778df3a42fce70c67cac29b2d96e/main/gps.go#L1945 Unfortunately I'm not sure what could really go wrong here. Maybe add a Flush() between the 2 write commands? Maybe remove the read-command? I don't know.. if you have any trial-and-error ideas go ahead. Maybe you could also try to send the string without the checksum, just for the sake of testing: https://github.com/b3nn0/stratux/blob/b4d0ca1f0f21778df3a42fce70c67cac29b2d96e/main/gps.go#L1937 OGN Tracker accepts commands without checksum as well, but if a checksum is given, it must be correct.
3. Maybe add some logging here and log the entire GPS communication for testing: https://github.com/b3nn0/stratux/blob/b4d0ca1f0f21778df3a42fce70c67cac29b2d96e/main/gps.go#L2079 just to see if maybe OGN Tracker reports some error via serial?
4. Maybe interesting: Which usb-to-serial chip does your T-Beam have? See lsusb. The 2 I have are both older CP210x T-Beams..
5. I can see there is now a newer RPi Kernel in the repositories.. maybe try and apt update && apt upgrade and reboot and try again?

[scheuss]

I think it is exactly as you mention. The first request is going through, the following ‘set tracker’ did not get a response. See file ‘Log_eu30-version.log’ at line 13 the configs are received the first time. At line 43 and 54 I tried to set a new OGN Tracker setting but I did not get a response.

I also tried to set new configs with the old version, see ‘Log_eu29-version.log’. Here Stratux is sending the configuration and get a response every time as it should be.

To your suggestions:

1. I commented out the line ‘dtoverlay=dwc2’ and restart the Stratux -> no change (I did not rebuild Stratux, hope that is correct)

2. I will play around a bit, if nothing works, I will connect to the RX&TX line on the T-Beam and log the serial communication. I think there should be something different between eu29 and eu30.

3. I can try that.

4. Interesting, I have a different chip, CH9102F. See the pictures attached.

The output of lsusb is:

root@stratux:~/stratux# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 1a86:55d4 QinHeng Electronics USB Single Serial
Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@stratux:~/stratux#

5. I tried that but is does not change anything.

I will do more testing next week and post my results here.

Log_eu29-version.log Log_eu30-version.log

[b3nn0]

re 1. Alright.. that's somewhat good to hear because removing that option it in practice wouldn't be an option, and no idea how we could work around that. re 4. Yes, the T-Beam was delivered with various different serial chips. The CP210x one was on older builds, the QinHeng one was on the later ones. Not sure what they use nowadays. Unfortunately I don't have a QinHeng T-Beam.. if that's what's causing the issue at all (but it kinda feels like it tbh).

[scheuss]

I measured the TX signal after the CH9102F. The data from RPi to TBeam. See the signals in the picture below. The startup looks a bit different. The ‘Set Baud?’ differs in byte length, it looks like the baud is changing. The ‘Configuration’ block is for eu29-version always 558 bytes long. For the eu30-version only 288 bytes. Any idea why?

If I press ‘Configure OGN Tracker’ on the eu29-version, the byte string is always 115 byte long. For the eu30-version it is only 64 bytes long. The last part is cut away. See the picture. Playing around with flush or comment out the check sum does not change anything. Press ‘Configure OGN Tracker’ on eu29-version (115 bytes):

Press ‘Configure OGN Tracker’ on eu30-version (64 bytes):

The log output shows that for both software versions the GPS config ‘/dev/serialin’ was used.

I exported both serial communications and compare it in the excel sheet. They are not the same, but I think they should. (The configuration block starts at the yellow line) Any idea? MessageDebugging_eu29_eu30.xlsx

[b3nn0]

Wow, that's a very thorough analysis, I'm impressed. What scope/analyzer did you use to get these graphs with annotated text? Anyway: No, the messages should not be exactly the same for EU029 and EU030, as there were changes on how the GPS is configured (BeiDou vs GLONASS, some power management setting was removed, GNGST output enabled). So at least the first couple differences are absolutely expected. I'd rule out all the UBlox commands for now and focus on the $POGNS stuff. From what I see this excel sheet is without a click on the configure button?

Anyway, as you can see from the code, there is no way Stratux would only send the first part of the message, as your signal graph shows. So it must be some lower level issue. Driver comes to mind, since there was quite a large jump in kernel versions in eu030 (switch from Bullseye to Bookworm). Anyway.. since only the end is missing, and the first part is transmitted perfectly fine.. what happens if you simply press the configure button 1-2 more times? I wonder if the rest is actually dropped, or just stuck in some outbound buffer which is never flushed correctly, and adding more data do it would write the older parts.

GPS related commits in EU030: Removed UBX-CFG-PMS: 64edd25e48d51378c87837976aca09865d7ad9fd Revert to GLONASS instead of BEIDOU: dd49b573a763142ba6196f1a0401783f8ed32565 Enable GNGST: 081f27a6a24a4d355be9539a6639b05eebf09f4e and eab5115304a4578fec16821cc2ed02c5f9352f34

Not 100% sure that's all, but I think so.

[b3nn0]

Oh, one more idea I just had: You could try what happens if you take the Stratux software stack (and it's outdated go serial library) out of the equation, by just issuing the respective config command directly from the command line. Something like this should work (not tested though). If needed, change some values and remove the checksum.

stty -F /dev/serialin 115200 raw -echo
echo -e "$POGNS,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n" > /dev/serialin

[scheuss]

Thank you but nothing compared to the effort you are investing into this project. I have to thank you. I am using a Saleae Logic 16 with its software. I borrowed it from work. If that much in configuration has changed, I was on the complete wrong track. If I press the configure button several times with or without changing the tracker address or registration, the length is always the same. 64 byte long, starts with ‘$POG…’ ends with ‘…,Reg=OECWS,T’. Of course, the address and reg inside the string is changing depending on my settings. It looks like the last part is just dropped and the next transmission starts correct.

Excellent idea to just try to send data via console.

If I send your suggested string:

stty -F /dev/serialin 115200 raw -echo
echo -e "$POGNS,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n" > /dev/serialin

I get the following transmission in the serial communication: ,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n\n

I if send it several times the result is always the same. I am not sure why there are two ‘\n’ at the end, maybe it is adding one automatically.

If I send: echo -e "ATESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTEESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTEB\r\n" > /dev/serialin

I get the following transmission in the serial communication: ATESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTEESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTESTTEB\r\n\n This is > 140 bytes, the length should not be a problem.

If I send (without the $-character): echo -e "POGNS,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n" > /dev/serialin

I get the following transmission in the serial communication: POGNS,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n\n

If I send: echo -e "P$OGNS,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n" > /dev/serialin

I get the following transmission in the serial communication: P,Address=0x3D1327,AddrType=1,AcftType=8,Pilot=,Reg=DEFMT,TxPower=31,Hard=STX,Soft=1.6r1-eu030*3A\r\n\n

If I send: echo -e "$$$$$$$$$$\r\n" > /dev/serialin

I get the following transmission in the serial communication: 987987987987987\r\n\n

If I send (\x24 = $, \x41 = A): echo -e "\x24\x24\x41\r\n" > /dev/serialin

I get the following transmission in the serial communication: $$A\r\n\n

It seems there is a problem with the dollar character. At least with the command line. With the normal stratux serial, the $ is transmitted correct but the end is missing. Any ideas? Maybe I can try to send different string inside the gps.go file

[b3nn0]

No worries, the $ in bash will try to resolve environment variables, forgot about that. So $POGNS will resolve to empty string, because that variable is not defined of course. Double \n is added by echo, yes.

So generally, I think we can conclude that stuff works correctly from the terminal, just not from Stratux. I am lost.. no idea what could cause that..

[b3nn0]

Actually.. I do have one more idea. I checked the tarm/serial library that Stratux uses. It seems to be a more or less simple wrapper around low level libc calls. To write to serial, it simply uses the write() system call. I checked the man page of that, and:

      On success, the number of bytes written is returned.  On error,
       -1 is returned, and [errno](https://www.man7.org/linux/man-pages/man3/errno.3.html) is set to indicate the error.

       Note that a successful write() may transfer fewer than count
       bytes.  Such partial writes can occur for various reasons; for
       example, because there was insufficient space on the disk device
       to write all of the requested bytes, or because a blocked write()
       to a socket, pipe, or similar was interrupted by a signal handler
       after it had transferred some, but before it had transferred all
       of the requested bytes.  In the event of a partial write, the
       caller can make another write() call to transfer the remaining
       bytes.  The subsequent call will either transfer further bytes or
       may result in an error (e.g., if the disk is now full).

So maybe for your serial chip, we do hat some of the "various reasons" that could result in only a partial write, whatever that reason may be. So let's try to be a good boy and actually check the number of bytes returned by write().. If you want, you could just add some logging there to see what is actually returned by the Write() call.

You might also want to add this function somewhere in gps.go:

func SerialWriteAll(p *serial.Port, b []byte) (n int, err error) {
    written := 0
    for written < len(b) {
        curr, err := p.Write(b[written:])
        if err != nil {
            logErr("Serial write to GPS failed: " + err.Error())
            return written, err
        }
        written += curr
        if curr < len(b) {
            logInf("Partial write detected: Wrote %d of %d bytes", curr, len(b))
        }
    }
    return written, nil
}

Then call SerialWriteAll(serialPort, data) instead of serialPort.Write(data). Note that I have added some more elaborate logging in there, so we know if this is actually what's happening. Only tested the function rudimentarily, as Write() always returns the full amount of data for me.. Write() == len(b) .

[scheuss]

I didn’t know that with the $. In this case it is okay.

I tried you suggestion with the return of write() I modified the function configureOgnTrackerFromSettings() as follow:

func configureOgnTrackerFromSettings() {
    if serialPort == nil {
        return
    }

    cfg := getOgnTrackerConfigString()
    log.Printf("Configuring OGN Tracker: " + cfg)

    log.Printf("Start transmission")
    value1, error1 := serialPort.Write([]byte(getOgnTrackerConfigString()))
    value2, error2 := serialPort.Write([]byte(getOgnTrackerConfigQueryString())) // re-read settings from tracker
    serialPort.Flush()

    if error1 != nil {
        logErr("Serial write to GPS failed: " + error1.Error())
    }
    log.Printf("Data wrote %d of %d bytes", value1, len([]byte(getOgnTrackerConfigString())))

    if error2 != nil {
        logErr("Serial write to GPS failed: " + error2.Error())
    }
    log.Printf("Data wrote %d of %d bytes", value2, len([]byte(getOgnTrackerConfigQueryString())))
}

The log shows: 2024/05/02 21:04:00 Configuring OGN Tracker: $POGNS,Address=0x440284,AddrType=3,AcftType=8,Pilot=,Reg=OECEF,TxPower=31,Hard=STX,Soft=1.6r1-eu030*52 2024/05/02 21:04:00 Start transmission 2024/05/02 21:04:00 Data wrote 104 of 104 bytes 2024/05/02 21:04:00 Data wrote 11 of 11 bytes

It looks like everything is transmitted. I also tried your code with the same result. The log says all bytes are transmitted but with the serial decoder I am still missing the end. No success here.

I then tried some more things like add delays. Surprisingly, with a delay between write() and flush() in the function configureOgnTrackerFromSettings() I got the complete transmission. Perfect! If I add 5ms, some transmissions are got some bad, if I add 6ms it works every time.

serialPort.Write([]byte(getOgnTrackerConfigString()))
serialPort.Write([]byte(getOgnTrackerConfigQueryString())) // re-read settings from tracker
time.Sleep(6* time.Millisecond)
serialPort.Flush()

Any idea why? I don’t have a very deep understanding in Linux. Would it make sense to add a delay before each flush()?

[b3nn0]

That is very strange. Flush is supposed to write everything in queue, not discard it. What if you remove the flush all together? It's probably unnecessary anyway..

[scheuss]

Yes indeed it is strange. I just tested it, works also perfect without flush() and delay. Do you think it is a good idea to just comment out all flush() lines?

[b3nn0]

Yes that should be fine. I am traveling right now, will remove them when I am back.

[scheuss]

Okay perfect, thanks for your support

[KBfly]

Hallo,

ich hänge mich hier mal mit rein. Von meinen gebauten Stratuxen habe ich nunmehr 6 auf die Version 0.30 upgedatet. -> Problemlos! Ein 7. Stratux hat das hier beschriebene Problem extakt genau so. Leider kann ich keine Tests dazu anbienten (was hier nicht weiter hilft ...ich weiß), da das Gerät bereits wieder beim Fliegerfreund zurück ist.

Vorgänge: Stratux:

• Update von 0.29 auf 0.30 -> o.k. T-Beam: (ich setze eine Version mit OLED ein)
  • Update -> o.k.

--> Reboot (bzw. aus)

• T-Beam Konfig im Webfrontend Stratux eingetragen und an T-Beam senden -> geht nicht! -> das konnte ich sofort am OLED erkennen!
• T-Beam wird im Webfrontend unter der Traffic Anzeige richtig erkannt und dargestellt. (Zuordnung via ogn db file???)
• T-Beam alte Version geflasht
• Erneuter Versuch Konfig via Webfrontend Stratux und an T-Beam senden -> geht nicht! ....für mich an der Stelle der "Beweis" es liegt an der 0.30 Stratux

weiter....

• T-Beam wieder aktualisiert/geflasht
• Karte mit 0.29 Version in Stratux
• jetzt T-Beam Konfig im Webfrontend eingetragen und an T-Beam gesendet --> o.k. geht!
• alles aus
• jetzt Karte mit 0.30 Stratux in Stratux und gestartet
• T-Beam wird schon richtig ausgelesen (Konfig steht richtig im Webinterface und auf dem OLED des T-Beam)

Wie gesagt, das war von den Stratuxen bisher nur Einer! 6 Stck. funktionierten problemlos. Technisch waren die Geräte allle gleich. Was die Platinen/Chip Daten betrifft kann ich leider keine Aussage zu machen.

Ich weiß, für eine Fehlersuche hilft das hier nichts, ggf. jedoch trotzdem interessant.

viele Grüße, Karsten

[scheuss]

Sieht schon sehr wie mein Problem aus. Bei mir hat das Auslesen vom T-Beam auch immer funktioniert, jedoch neu konfigurieren nicht. Falls du das 7. Gerät mal wieder in der Hand hast, wäre ein Blick auf den Serial-USB-Chip auf dem T-Beam sehr interessant. Vielleicht ist bei diesem Gerät ja wirklich ein CH9102F wie bei mir bestückt.