Stereo Tool

Hello,

I am able to get a green "Lock" in SFN mode successfully, however, when I try to activate audio delay measurement, the 1pps pulses immediately got lost.

Has anybody experienced a similar problem?

Before activating the delay measurement:



After activating the delay measurement:




Hardware is RPI4 + HifiBerry DAC+ ADC Pro. The 1pps signal if fed from the LEA-M8F GPS module (50% duty cycle) to the left input channel. The right input channel is connected to the right output channel for the loopback delay measurement. The measured delay varies from about 40 to about 60 ms after rebooting the RPI, so I definitely need to activate this feature.

Another customer just ran into this same issue 2 weeks ago! There was indeed a bug in the code that could cause this to happen when a specific combination of things happened (all timing related, so whether it happens depends on your hardware speed, exact sound card speed, 1PPS timing etc).

It's fixed in the latest version - we just released that 5 minutes ago. Please update to MicroMPX 4.3.3 and let me know if that fixes is.

Thank you very much for paying attention to fixing this problem.

Unfortunately, I was unsuccessful with version 4.3.3. The "IO loopback delay" still cannot be measured, since after running for some time, the program loses the "GPS NMEA data". Once I turn off "GPS SFN" and turn it back again, the "GPS NMEA data" stays green for a minute or so, and then is lost again.

Screencast:

https://www.pcs-electronics.com/wp-cont ... -00-27.mp4

P.S. The "GPS NMEA data" is lost even without turning on the "Measure IO loopback delay".

Playing with MicroMPX decoder, I tried to change the baudrate of the GPS receiver. I noticed that the "Baudrate" setting in the "NMEA" setting box does not have any effect: for instance, when I set 115200 the program can still decode NMEA data sent at 9600 baud, but not 115200 baud. I tried to reboot, but it did not help. Only the

stty --file /dev/ttyS0 115200

command actually lets MicroMPX decoder accept NMEA data at 115200 (until the next reboot).

The /home/thimeo/.MicroMPX_Decoder.rc file contains

Thimeo MicroMPX GPS NMEA device baud rate=115200
Thimeo MicroMPX GPS NMEA device name=/dev/ttyS0

But in fact the MicroMPX decoder starts with the 9600 baud.

After manually setting the baudrate to 115200 by the stty command, I run it again to check:

thimeo@thimeo-pi:~ $ stty --file /dev/ttyS0
speed 115200 baud; line = 0;
min = 0; time = 20;
-brkint -icrnl -imaxbel
-isig -icanon -echo -echoe

As it should be, I see 115200 here. But when I touch the "Baudrate" setting in the MicroMPX decoder and select any value (such as 4800), the baudrate is set back to 9600:

thimeo@thimeo-pi:~ $ stty --file /dev/ttyS0
speed 9600 baud; line = 0;
min = 0; time = 20;
-brkint -icrnl -imaxbel
-isig -icanon -echo -echoe



In addition, I notice the program writing enormous log files (160 MB at the time, running MicroMPX decoder for a few hours in total) to /home/thimeo/thimeo/log.software/ . The logfile is updated every fraction of a second:

2025-12-08 11:55:01.963 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:01.963 trace: Decoded packet 3351090250 from stream on port 8854
2025-12-08 11:55:01.973 trace: MicroMpxReceiver: Received a packet of 415 bytes, ts 3351092290, duration 2040, reset 0, port 8854
2025-12-08 11:55:01.973 trace: MicroMpxBlockDecoder: Received packet timestamped 3351092290, duration 2040, size 415 bytes
2025-12-08 11:55:01.973 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:01.974 trace: Decoded packet 3351092290 from stream on port 8854
2025-12-08 11:55:01.978 trace: MicroMpxReceiver: Received a packet of 407 bytes, ts 3351094330, duration 2040, reset 0, port 8854
2025-12-08 11:55:01.978 trace: MicroMpxBlockDecoder: Received packet timestamped 3351094330, duration 2040, size 407 bytes
2025-12-08 11:55:01.978 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:01.979 trace: Decoded packet 3351094330 from stream on port 8854
2025-12-08 11:55:01.983 trace: MicroMpxReceiver: Received a packet of 410 bytes, ts 3351096370, duration 2040, reset 0, port 8854
2025-12-08 11:55:01.983 trace: MicroMpxBlockDecoder: Received packet timestamped 3351096370, duration 2040, size 410 bytes
2025-12-08 11:55:01.984 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:01.984 trace: Decoded packet 3351096370 from stream on port 8854
2025-12-08 11:55:01.998 trace: MicroMpxReceiver: Received a packet of 409 bytes, ts 3351098410, duration 2040, reset 0, port 8854
2025-12-08 11:55:01.998 trace: MicroMpxBlockDecoder: Received packet timestamped 3351098410, duration 2040, size 409 bytes
2025-12-08 11:55:01.998 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:01.999 trace: Decoded packet 3351098410 from stream on port 8854
2025-12-08 11:55:02.005 trace: MicroMpxReceiver: Received a packet of 410 bytes, ts 3351100450, duration 2040, reset 0, port 8854
2025-12-08 11:55:02.005 trace: MicroMpxBlockDecoder: Received packet timestamped 3351100450, duration 2040, size 410 bytes
2025-12-08 11:55:02.005 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:02.006 trace: Decoded packet 3351100450 from stream on port 8854
2025-12-08 11:55:02.010 trace: MicroMpxReceiver: Received a packet of 412 bytes, ts 3351102490, duration 2040, reset 0, port 8854
2025-12-08 11:55:02.010 trace: MicroMpxBlockDecoder: Received packet timestamped 3351102490, duration 2040, size 412 bytes
2025-12-08 11:55:02.010 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:02.011 trace: Decoded packet 3351102490 from stream on port 8854
2025-12-08 11:55:02.019 trace: MicroMpxReceiver: Received a packet of 411 bytes, ts 3351104530, duration 2040, reset 0, port 8854
2025-12-08 11:55:02.019 trace: MicroMpxBlockDecoder: Received packet timestamped 3351104530, duration 2040, size 411 bytes
2025-12-08 11:55:02.019 trace: Running decoder worker: 408 samples to decode
2025-12-08 11:55:02.020 trace: Decoded packet 3351104530 from stream on port 8854

I wonder how soon the SD card will be full.

I also tried RIST mode, but could never get the upper "GPS Lock" working.

Sorry, I had missed your previous message! That behavior looks bizarre.

The logging stops when a GPS lock is aquired, so that wouldn't be a problem under normal circumstances.

But I don't know why it doesn't aquire a GPS lock. I can't see the full screen, is the latency (buffer size) too low? I know that that can be an issue, also depending on which hardware you use. What is very weird is that the detected GPS NMEA time stamps seem to be a second behind.

I'll need to check the bitrate behavior. We should be opening the connection with the specified bitrate, but I think all the GPS receivers that I have used for testing work at 9600 baud. So that might have hidden any issues. I have put checking this on top of our todo list.

So, questions:
- Which hardware GPS receiver are you using for the NMEA? Is that also coming from the LEA-M8F GPS?
- What happens if you increase the latency setting, for example to 2 seconds?


Edit: I need to check it tomorrow (I need to plug in the hardware to properly test it) but I found something very suspicous in the code. It looks as if changing the settings in some cases might be ignored, at least until GPS has been turned off and back on again. Anyway, I need access to the hardware to plug a GPS receiver into a test system to verify if this behavior is indeed broken.

Hello, and thank you very my for replying my message.

What happens if GPS lock is never acquired? I am sure the transmitter does not have to die (SD card full) because the GPS antenna is damaged. At least, it should keep working in non-SFN mode.
115200 is needed in my case because there is another microprocessor on the same serial line reading additional information from the GPS receiver (same LEA-M8F), such as satellite signal levels, "survey-in" status, external OCXO status, etc. There is simply not enough bandwidth at 9600 to send all this data within 1 second intervals, so at 9600 some of NMEA packets (including the ones carrying time) may be just dropped or delayed, then received too late. As you said, "What is very weird is that the detected GPS NMEA time stamps seem to be a second behind". It looks like MicroMPX decoder software is getting crazy and is losing sync in the case.

I remember I played with the latency slider, but have not got any improvement.

The only case it worked at my side is when I forcedly switched the program to use 115200 baud by entering

stty --file /dev/ttyS0 115200

In this case, all the NMEA data was sent within 1 second -> no packet loss, no delays more than 1 second -> MicroMPX decoder is happy -> No sync lost


I will be really happy if 115200 work without any tweaks Notice I need the hardware serial port (with "real" baudrate), not the virtual USB serial port connection (with "virtual" baudrate, which does not have effect).

For the debugging purposes, the baudrate setting should be easy to discover even on such a virtual USB port, such as:

stty --file /dev/ttyUSB0

Thank you,

Denis.