MB device does not show traffic in Skydemon

[Sylvain C.]

Hi all,

My MB166 T-Echo does not show the traffic that it is receiving on the Skydemon map. 

This does work correctly with XCsoar. 

I also notice that before departure, the position info received by the T-Echo does not show “on the ground” and does not show the runway symbol in the virtual radar banner. 

With my T-Beam supreme running Linar’s SoftRF I can see the received traffic on Skydemon. 

What could the reason for this?

[Moshe Braner]

Sylvain:  First make sure the connection to the Skydemon is working.  Is any other data (GPS location, pressure altitude (if you have that sensor)?) getting through to Skydemon?  Also make sure the "traffic" data is selected in SoftRF to be sent out.  (If it works with XCsoar, then that's set up OK, if both are using the same output from SoftRF, the primary one or the secondary one.)  There may be other issues I haven't though of, and I don't use Skydemon.  Skydemon users in this Group may offer advice.

The “on the ground” etc things sound like Skydemon features.  There is nothing in the PFLAA sentence (sent out by SoftRF) to say whether that traffic is airborne or not.  It does include the aircraft's ground speed, maybe Skydemon bases it on that.  (What does it show for a glider that is "hovering" in mountain wave, with the airspeed equal the wind speed resulting in zero ground speed?)  Or maybe Skydemon doesn't try to determine that?  ADS-B signals, in contrast, are distinctly different for airborne and non-airborne aircraft.

[Sylvain C.]

Thanks Moshe for the quick reply!

My T-Echo is equipped with the BMP280 sensor. Startup screen shows '+' for all items (including BARO), with the exception of IMU which shows '-'

It is running MB166 software and is setup as follows:

Normal

NMEA1: BLT GST

Skydemon shows my own position correctly.

I am wondering if the fact that it does not display 'on ground' and does not show the runway symbol in the virtual radar might be related to the pressure altitude data?

The e-ink display correctly shows other SoftRF devices on the traffic display but this traffic does not appear in Skydemon.

I'd like to add the following screenshots to illustrate the issue.

Screenshot 1

T-Beam Supreme running SoftRF by Linar connected to Skydemon

Own position correctly displayed

- When powering up T-Echo device to simulate aircraft proximity -

Both devices correctly start exchanging TX and RX data

'On ground' message and airport symbol in virtual radar shown

T-Echo running MB166 correctly shown on Skydemon as FLR_xxxxxx

Image

Screenshot 2

T-Echo running MB166 connected to Skydemon

Own position correctly displayed

- When powering up T-Beam Supreme device to simulate aircraft proximity -

Both devices correctly start exchanging TX and RX data

'On ground' message and airport symbol in virtual radar NOT shown

T-Beam Supreme running SoftRF by Linar is NOT shown in Skydemon

Image

I hope someone can help me get to the bottom of this as I really like the added features of the MB software but without seeing the traffic on screen on my EFB, it severely reduces the usability.

Thanks!

Sylvain

[VirusPilot]

I believe the reason ist that by default, MB166 does not provide $GNGSA sentences which are required by SkyDemon to provide GPS altitude.

Changing the configuration in the T-Echo is a bit cumbersome because you need to edit the config file while your T-Echo is connected to the PC.

Moshe, it would be good to have a simple file that includes all the configuration options and maybe a few examples, e.g. how to enable $GNGSA.

Sylvain C. schrieb am Donnerstag, 30. Oktober 2025 um 18:59:34 UTC+1:

I just noticed the sensor on my T-Echo is a BME280.
That is different to the BMP280... can this cause the issue?

Is MB166 compatible with the BME280 sensor?

Thanks

[Sylvain C.]

That was it! Thank you VirusPilot!!

I modified settings.txt with 

nmea_g,03          # 0=off 1=basic 3=GSA ...

I now see my other SoftRF device showing up in Skydemon.

I also now see the 'on ground' and Runway symbol in the Virtual radar.

Looking forward to my next flight to test this out.

Have a great evening gentlemen!

[VirusPilot]

Happy that I could resolve this issue. 

[Sylvain C.]

If Moshe would find some time to describe a bit more in detail the various nmea settings in a future release that would be great indeed...

I'm trying to learn more about this by reading up on the internet but it's not easy to comprehend for a novice.

I now found that GNGSA sentences deal with fix mode, satellite IDs, and dilution of precision values...
I could not find a direct relation to altitude transmission so I'm trying to further get head around this.

I think I'm gonna compare some logs to see the impact of the parameter I changed. :-)

Cheers,
S.

[Nick Bonniere]

The NMEA GSA sentence only provides status information about the satellites in view and satellites used. This status information is not required for anything but providing satellite status information. All navigation information is provided by RMC for position, GGA for GNSS altitude, and RMZ for pressure altitude.

It is Skydemon that wants the GSA information before it processes anything. So it's a question to ask Skydemon as to why they need it when  XcSoar and other software do not require it. It is possibly because they want to confirm the GNSS fix is 3D and not just 2D.

---

On 30-Oct-2025 15:31, Sylvain C. wrote:

[Moshe Braner]

I'll try and add something about that in the documentation.  I don't have personal experience in all the uses of SoftRF, e.g., with Skydemon, so can't anticipate that.  That's what this Group is good for, as you can see!  Thank you all.

So sounds like Skydemon is picky about getting the GSA sentences, otherwise it refuses to assume that the fix is good.  I'd say that's a flaw in Skydemon.  But we do have the way to satisfy it.

Did you find the procedure of editing and saving the settings.txt file easy enough to follow?

The current "under the hood" document does include this somewhat-cryptic text:

"Some settings are now bitfields - these are two hexadecimal digits:
nmea_g & nmea2_g - 1 for basic (GGA+RMC), 2 for GSA (3 for basic+GSA), 4=GST 8=GSV F=all
nmea_s & nmea2_s - 1 for basic (PGRMZ), 2 for LK8EX1 (3 for both)

..."

On Thursday, October 30, 2025 at 3:31:44 PM UTC-4 Sylvain C. wrote:

If Moshe would find some time to describe a bit more in detail the various nmea settings in a future release that would be great indeed...

I'm trying to learn more about this by reading up on the internet but it's not easy to comprehend for a novice.

I now found that GNGSA sentences deal with fix mode, satellite IDs, and dilution of precision values...
I could not find a direct relation to altitude transmission so I'm trying to further get head around this.

I think I'm gonna compare some logs to see the impact of the parameter I changed. :-)

Cheers,
S.

On Thursday, October 30, 2025 at 8:23:34 PM UTC+1 VirusPilot wrote:

Happy that I could resolve this issue. 

Sylvain C. schrieb am Donnerstag, 30. Oktober 2025 um 19:39:28 UTC+1:

That was it! Thank you VirusPilot!!

I modified settings.txt with 

nmea_g,03          # 0=off 1=basic 3=GSA ...

I now see my other SoftRF device showing up in Skydemon.

I also now see the 'on ground' and Runway symbol in the Virtual radar.

Looking forward to my next flight to test this out.

Have a great evening gentlemen!

On Thursday, October 30, 2025 at 7:12:17 PM UTC+1 VirusPilot wrote:

I believe the reason ist that by default, MB166 does not provide $GNGSA sentences which are required by SkyDemon to provide GPS altitude.

Changing the configuration in the T-Echo is a bit cumbersome because you need to edit the config file while your T-Echo is connected to the PC.

Moshe, it would be good to have a simple file that includes all the configuration options and maybe a few examples, e.g. how to enable $GNGSA.

...

[Moshe Braner]

The GGA sentence includes the number of satellites in view, that should have been enough for Skydemon.  (Need at least 4 satellites to get a 3D fix.)  But we can't control what Skydemon does.  Won't hurt to ask them though.

[Sylvain C.]

I will raise the question with Skydemon and report back if I get a reply or statement.
That is something where I can help so you don't need to spend time on that! :-)


Quote: Did you find the procedure of editing and saving the settings.txt file easy enough to follow?
I did. The under the hood document helped me out after reading VirusPilot's post above.
I just was not able to figure out what I was changing exactly by going from basic to GSA, but that is because of my very limited knowledge about this stuff as a novice.
A few additional lines like Nick posted might already make a difference for new joiners.

Why limiting the nmea sentence to basic by default and not have it set on FULL for example?
Is that to focus the (limited) processing power of the hardware on the relevant bits of info?
Would FULL cause too much data to process efficiently?

Thanks to all of you for chiming in.

Really appreciate it.

[Moshe Braner]

If the baud rate of a serial connection is low (19200 or even less), and if there is a lot of traffic to report, including the GSA may be problematic.  What do you all think, should the default be "basic" (RMC+GGA only) or include the GSA?  How many uses need the GSA?  At least the settings now allow turning the GSA on or off as needed.

On Thursday, October 30, 2025 at 4:41:29 PM UTC-4 Sylvain C. wrote:

...

[Sylvain C.]

I would not change the basic setting if that can be problematic for some hardware setups.
Especially as you - glider pilots - often fly with lots of traffic around in close proximity.
It seems only Skydemon is picky about the GSA for now, so simply mentioning it in the doc would be the way to go in my opinion.

[VirusPilot]

I have already discussed this with Tim from SkyDemon already in the past - they process only the VDOP field from $GNGSA because this is the only standard NMEA message which carries such information.

[Moshe Braner]

If the Skydemon people want, they can detect a SoftRF device attached (via the PSRFH "heartbeat" sentences that it sends once in 10 seconds) and then send a configuration query sentence to SoftRF:

    $PSRFS,0,nmea_g,?

and if necessary then turn on the GSA, save settings, and reboot:

    $PSRFS,1,nmea_g,3

(See the "under the hood" document.)  This assumes the data connection is bi-directional - Bluetooth is.  (Note that the connection may instead be via the secondary NMEA port nmea2.)

I believe Stratux already does something like this.