OXS 2040 with Jeti EX-Bus

[Klippeneck]

Hello mstrens, just played version 2.3.0 on my testboard, with protocol Jeti J it works with MS5611 and Beitan GPS220. As a test I only changed the protocol to Jeti EX Bus, then I don't see the sensor in the transmitter. Receiver input was set to EX bus and sensor configured accordingly. Has anyone else done tests with Jeti? Attached is the config file. Greetings Jürgen Version = 2.3.0 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 28 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 29 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 26 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 27 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 255 255 255 255 (V1 / V4 = 26, 27, 28, 29)

Protocol is Jeti (Exbus) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is not detected Airspeed sensor is not detected Vspeed compensation channel = 0 First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox (configured by oXs) :GPS is detected but has not (yet) a fix Failsafe type is HOLD

Config parameters are OK Press ? + Enter to get help about the commands

[Klippeneck]

Hello mstrens, with SW 2.4.9 and without SDA and SCL, GPS Lat is stable and correct. GPS cum. dist. shows 3200km after start-up, so it is not yet correct. Attached is the USB output with FVP and FVN. FVP processing cmd

Cmd to execute: FVP

GPS Latitude = 89.1234560 degree GPS Longitude = 178.1234560 degree GPS Groundspeed = 2468 cm/s GPS Heading = 179.120000 degree GPS Altitude = 135721 cm GPS Num sat. = 23 GPS Date J M A = 16 4 23 GPS Time H M S = 34 19 49 GPS Pdop = 123 GPS Home bearing = 179 degree GPS Home distance = 234 m Volt 1 = 7321 mVolt Current (Volt 2) = 89321 mA Volt 3 = 15321 mVolt Volt 4 = 14321 mVolt Capacity (using current) = 34321 mAh Temp 1 (Volt 3) = 136 degree Temp 2 (Volt 4) = 148 degree Vspeed = 258 cm/s Baro Rel altitude = 246821 cm Pitch = 89 degree Roll = 78 degree Yaw = 67 degree RPM = 369 Hertz Ads 1 1 = 11111 mVolt Ads 1 2 = 12121 mVolt Ads 1 3 = 13131 mVolt Ads 1 4 = 13141 mVolt Ads 2 1 = 21212 mVolt Ads 2 2 = 22222 mVolt Ads 2 3 = 23232 mVolt Ads 2 4 = 24242 mVolt Airspeed = 15151 cm/s Compensated Vspeed = 167 cm/s Sbus hold counter = 98 Sbus failsafe counter = 12 Gps cumulative distance = 135791 Vspeed compensation = 1.10 Internal telemetry fields are now filled with POSITIVE dummy values To get real values again, you have to power down

FVN processing cmd

Cmd to execute: FVN

GPS Latitude = -89.1234560 degree GPS Longitude = -178.1234560 degree GPS Groundspeed = 0 cm/s GPS Heading = -179.120000 degree GPS Altitude = -56721 cm GPS Num sat. = 0 GPS Date J M A = 16 4 23 GPS Time H M S = 34 19 49 GPS Pdop = 3 GPS Home bearing = -179 degree GPS Home distance = 0 m Volt 1 = -7321 mVolt Current (Volt 2) = -89321 mA Volt 3 = -15321 mVolt Volt 4 = -14321 mVolt Capacity (using current) = 0 mAh Temp 1 (Volt 3) = -19 degree Temp 2 (Volt 4) = -21 degree Vspeed = -258 cm/s Baro Rel altitude = -46821 cm Pitch = -89 degree Roll = -78 degree Yaw = -67 degree RPM = 0 Hertz Ads 1 1 = -11111 mVolt Ads 1 2 = -12121 mVolt Ads 1 3 = -13131 mVolt Ads 1 4 = -13141 mVolt Ads 2 1 = -21212 mVolt Ads 2 2 = -22222 mVolt Ads 2 3 = -23232 mVolt Ads 2 4 = -24242 mVolt Airspeed = 0 cm/s Compensated Vspeed = -167 cm/s Sbus hold counter = 0 Sbus failsafe counter = 0 Gps cumulative distance = 0 Vspeed compensation = 1.10 Internal telemetry fields are now filled with NEGATIVE dummy values To get real values again, you have to power down

[KeesBlokland]

I guess the number of Sats being shown as 117, means I have a 3D fix (added 100) and the real value is 17? on 2.4.9 I just made these screencaptures, after only enabling Lat/Lon and Sats in the display and received tlm. Jeti_Tx_Screencap.zip Screen 005.bmp shows my real coordinates.)

[Klippeneck]

Hello mstrens, On closer analysis of the log file, there is only one value for Lat, but 82 values for Long. 09-41-02.log

[mstrens]

Indeed : when number of sat is greater than 100, it means that GPS has a fix. Number of sat is then the last 2 digits. It is strange that the format for Latitude change from GPS to date to degree. I must have a bug somewhere but I do not yet know where. Anyway, this fact will help.

[KeesBlokland]

Just so we do the same things: (and again thanks to all participating in this adventure. Things are moving so fast I hardly have time for a cup of coffee!)

In the video, I see that LON is also jumping. It seems that the other data (alt, speed) are not jumping (they just change slowly). It is also abnormal that the GPS cumulative distance is negative.
When you activate FVP, are LAT and LONG also jumping?

All sensors disabled, only GPS active.

Q: so even though FPV forced all values, the live GPS will replace the one you preloaded? I will do another one with one with FVP, and disconnect the output from the GPS, so that the preloaded values are not messed up.

From what I see it appears the values do not always end up in the correct display field.

On my terminal I get: `Cmd to execute: FVP

GPS Latitude = 89.1234560 degree GPS Longitude = 178.1234560 degree GPS Groundspeed = 2468 cm/s GPS Heading = 179.120000 degree GPS Altitude = 135721 cm GPS Num sat. = 23 GPS Date J M A = 16 4 23 GPS Time H M S = 34 19 49 GPS Pdop = 123 GPS Home bearing = 179 degree GPS Home distance = 234 m Volt 1 = 7321 mVolt Current (Volt 2) = 89321 mA Volt 3 = 15321 mVolt Volt 4 = 14321 mVolt Capacity (using current) = 34321 mAh Temp 1 (Volt 3) = 136 degree Temp 2 (Volt 4) = 148 degree Vspeed = 258 cm/s Baro Rel altitude = 246821 cm Pitch = 89 degree Roll = 78 degree Yaw = 67 degree RPM = 369 Hertz Ads 1 1 = 11111 mVolt Ads 1 2 = 12121 mVolt Ads 1 3 = 13131 mVolt Ads 1 4 = 13141 mVolt Ads 2 1 = 21212 mVolt Ads 2 2 = 22222 mVolt Ads 2 3 = 23232 mVolt Ads 2 4 = 24242 mVolt Airspeed = 15151 cm/s Compensated Vspeed = 167 cm/s Sbus hold counter = 98 Sbus failsafe counter = 12 Gps cumulative distance = 135791 Vspeed compensation = 1.10 Internal telemetry fields are now filled with POSITIVE dummy values To get real values again, you have to power down lat orig=351f2907 jeti=591cef Frame= 19 ef 1c 59 0 29 ef 1c b2 20 31 78 23 41 0 0 51 4d 5 61 17 0 1 a1 dc 42 d4 e4 22 40 e4 11 86 0 b1 d9 5b c1 f1 57 f1 88 0 1 10 94 0 4 12 6a 60 20 1 11 2 41 1 13 59 0 1 14 4e 0 4 16 7c 56 0 1 17 21 2 1 18 a7 40 ` There is no other output after this line, until I stop and start monitoring. Display on the Tx is what I see after a cold start of the RP2040, just watching the display. (video's are too big, hope this works too. )

Tx_screen_after_powerdown_all.zip

[mstrens]

In principe, when you use FVP(or FVN), the values provided by the sensors are overwritten by the fixed values. So there should be no mix in the telemetry.

In the log, it is indeed strange that:

• Lat is sent only once
• GPS Heading is missing in the list of fields (as name and in the values)
• the different fields are not always in sequence

Very strange.

[mstrens]

I found a bug in a table defining the length of the GPS cum distance. Version 2.4.11 is on github. Perhaps it help.

[KeesBlokland]

It surely is working now! I have a rock solid display with 14 sats at present! Cumulative probably adds up all the little random movements, so it will be a while before it shows anything. I'll start making a sensor for airborne tests!

On this GPS receiver I would normally not get any more then 12 sats on a good day, but removing all the nema stuff and only using the UBX certainly makes a difference (I think). This is with the receiver on a 5 meter extension lead (yep, that works too) just outside the door, so not really in a free sky-view. Btw I am using a Topgnss GB1803, that I have been using in varioGPS etc.

I'll start adding more sensors again.

Thanks again!

[mstrens]

I found a bug when there are many sensors. I hope I fix it in new version 2.14.12

[KeesBlokland]

2.14.12: So far so good!

[mstrens]

OK. If it is confirmed that it works, I will later on remove the remaining debug msg about exbus frames being generated

[Klippeneck]

Hello mstrens, SW 2.4.12 looks good, all telemetry values seem OK. Only GPS Heading I could not test, I will do tomorrow in flight if the weather plays along. Jürgen

[mstrens]

Thanks for testing and for the feedback. I removed the debug messages and so created version 2.5.0. I also copied this version into main branch.

[Klippeneck]

Hello mstrens, First test in flight today, so far everything is fine. Only the GPS cum. dist. seems to me a factor of 100 too small. After a 1 hour flight the value shows 0.5km, the correct value would be approx. 50km. Jürgen

[aepub]

The uf2 file compiled by oneself is still abnormal in Exbus mode. https://www.rcgroups.com/forums/showpost.php?p=51022293&postcount=1269

[mstrens]

I found the bug for cumulative dist. It was 100 too small. It is fixed in 2.5.1 (in test)

[KeesBlokland]

Thanks!, I'll try. Found another small one: also in 2.5.1

I just happen to have a bunch of BMP280's, it is not visible on the Transmitter, but is seen when I do a FV. (for my application it is a backup for the GPS altitude)

`Version = 2.5.1

Protocol is Jeti (Exbus) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is detected using BMP280 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is not detected Airspeed sensor is not detected No Vspeed compensation channel defined; oXs uses default settings First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox (configured by oXs) :GPS is detected but has not (yet) a fix Led color is inverted Failsafe type is HOLD ` 'Cmd to execute: FV

GPS Num sat. = 0 Vspeed = 0 cm/s Baro Rel altitude = 18 cm'

[KeesBlokland]

Q: How much work would it be, if it is at all possible, to add another I2C port?

This is probably something for the 'oh, would it not be nice' list.

Edit: In my test setup I have a BMP280 and a GY-521(MP6050). I guess the real reason behind the question was: If you put 2 I2C devices on the same lines, you need to (likely) remove one set of pull up resistors. And that can be a hassle. The BMP280 had 10k pull-ups, GY-521 has (only) 2k2. I removed the 10k ones from the BMP280 and all is well in the end:

' Protocol is Jeti (Exbus)

Baro sensor is detected using BMP280 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 0 , 0 , 0 Gyro offsets X, Y, Z = 0 , 0 , 0 Airspeed sensor is not detected` '

[Satcomix]

Q: How much work would it be, if it is at all possible, to add another I2C port?

This is probably something for the 'oh, would it not be nice' list.

Hello Kees, I2C is a bus system, why another connection? All modules work on the same bus. If you want to swap the I2C bus, from I2C1 to I2C0 it's easy. In VsCode in the tab: replace in files simply enter i2c1 and replace with i2c0. After that just do a build, done. Greeting, Torsten

[mstrens]

I fix the bug about detecting BMP280. The bug was there in the 2 jeti protocols. New version is on github.

Indeed why do you want another I2C bus?

[KeesBlokland]

I fix the bug about detecting BMP280. The bug was there in the 2 jeti protocols. New version is on github.

Indeed why do you want another I2C bus?

..lol, you are right, I did not have my proper coffee during the morning startup procedure!!

And yes, 2.5.1 gives me happy Vario-tones ;-) Thankyou!

[KeesBlokland]

The uf2 file compiled by oneself is still abnormal in Exbus mode. https://www.rcgroups.com/forums/showpost.php?p=51022293&postcount=1269

Just something to try? (Clean reconfigure, clean rebuild, clean)

[Satcomix]

The uf2 file compiled by oneself is still abnormal in Exbus mode. https://www.rcgroups.com/forums/showpost.php?p=51022293&postcount=1269

Just something to try? (Clean reconfigure, clean rebuild, clean)

Hello Mstrens, aepub, Kees, I'm starting to think that an update of Windows or Pico Visual Studio Code is responsible for the problems, because I also had problems this morning and first deleted all build folders. I have now installed everything again and created a build of version 2.5.2-test, which you could please check to see whether it works with your JETI system. On S.PORT and FBUS i have no problems with my own build. br, Torsten oXs.zip

[Klippeneck]

Hello mstrens, thanks for the change regarding Cum Dist., now it is correct. During today's test flight I noticed that the telemetry value GPS Heading was constantly set to 0. 1 hour flight, 33609 Items, but it is always zero. This seems to be another bug.

[mstrens]

There was indeed a bug for GPS heading in exbus. I hope I fix it now (loaded on github)

[Klippeneck]

Hello mstrens, With SW 2.5.3, the sensor no longer brings telemetry values, registration in the transmitter works.

[KeesBlokland]

Hi Thorsten, your Jeti version works here as well!

[Satcomix]

Hi Thorsten, your Jeti version works here as well!

Hello Kees, Thank you for this test with Jeti and my build created with Pico-Visual-Studio-Code under DEBUG mode. So all questions should have been clarified. Thanks very much, Greeting, Torsten

[mstrens]

I changed an option back in cmakelist.txt about getting compilation warning. It is on github (2.5.4). Not sure if this help.

[Satcomix]

I changed an option back in cmakelist.txt about getting compilation warning. It is on github (2.5.4). Not sure if this help.

Hello Mstrens, I did the 2.5.2 build in debug mode in VScode and it worked with JETI the same way as with FBUS and S.PORT. So why does something have to be changed now in cmakelist.txt, it worked all the months. Greeting, Torsten

[mstrens]

When I compiled, I did not get the warnings. I suspected that some compilation warnings should have been taken into account to solve the issue that some members had when they compiled them self. So I first made a change in cmakelist.txt in order to activate the warnings (I added a line "add_compile_options(-Wall)"). I had a look at some warnings and fixed some of them (about unused variables). It was version 2.5.3 It seems that the telemetry fields are not provided anymore in exbus. So I made now 2.5.4 where I remove the line for warnings hoping it is OK again.

[Klippeneck]

Hello mstrens, both 2.5.3 and 2.5.4 do not come up with telemetry values. Version 2.5.2 was the best working version so far, except that GPS haeding was missing. Jürgen

[mstrens]

I now put 2.5.5 where I reactivated an unused variable in exbus. I do not know if this will help.

If it does not help could you make a capture with the logic analyser with this 2.5.5 version.

[KeesBlokland]

ai, yes, something is broken. 2.5.3 is for me the last one that gives me GPS. Did not spot that, because I was working on roll&pitch in the workshop where I do not have gps reception. I was just looking at the output of the serial monitor. Me bad ;-( I'm going to build another setup to put in my plane, so that I can use the testing version on the workbench again. Don't know if I manage that this weekend though!

I will try to get a capture later.
Have a good weekend everybody, the sun is shining, looks like lots of flying today!

Kees

[mstrens]

I do not understand what is wrong. I just made a version 2.5.6 with no change to test (I only erased the content of the build directory, selected the kit GCC10.3.1 and compiled again)

[KeesBlokland]

It's a new sunny day, so let's try again ;-)

To create a baseline, I used 2.5.2, since that appears to be working as far as gps is concerned (minus the bugs that were discovered later. It gives me solid GPS readouts, so that is what I am looking for in the next releases. Hardware attached is a TOPGNSS GN203L, which has been flying for many a moon, nothing else.

After uploading the 2.5.2 to the rp2040, I shut down everything and prepare for capture.

The capture is from the self compiled version, where I only changed line 162 in exbus.cpp to show me the version I am working with on my transmitter.

{ 0 , "oXs252" , " " , EXBUS_TYPE_DEVICE, 0 , 0}, // identify the name of the device

Power up sequence: Start Logic Analyzer, turn on receiver side. Turn on Tx

• On power up of the Receiver side, we see a negative pulse on both GPS-TX/RX. Call this T0.
• At T+3Sec I can see 'B5 62 06 8A 1E 00 >> This is the init code for an M10. (Do I have an M10 chip? it is a TOPGNSS GN203L, which has a M8030-KT chip) GPS responds with B5 62 00 02 06 8A 97 BC. There are a few more exchanges you can see on the GPS Tx-Rx wires.
• At T+28sec I turn on the Transmitter and see the first sensible ex-bus string, and get a proper display. Since I already have a fix on the gps, the displayed values are there immediately.

Results are 14+ satellites and good GPS coordinates.

KB-2.5.2.zip

Next the same procedure with 2.5.6.

KB-2.5.6.zip MS-2.5.6.zip

Tx result: show 0°.0000'E and 0°0.000'N on Tx, no sats.

Next: have coffee and compare the two captures!

Going to try and produce an HTerm file as wel on the ex-bus, which makes it easier to find data? (he said hopeful). Druring my first attempt I did not see any 3D 01's in the Hterm data, so to make doubly doubly sure, I'll do the whole thing again from scratch. (MS-2.5.6)

Still can't find a 3D 01 sequence. Here are the two logs, one from Hterm, running in parallel with the Logic analyzer.

MS-2.5.6_Hterm.zip

Here's one from 18th May, Full of 3D 01 08 A7 3A, (send me telemetry plse). So, even if the receiver only sends it once, I should find that instance (me thinks) may18-rp2040.zip

3E 03: packet that forbids an answer 3D 01: packet with permission to answer

Where have our 3D 01's gone? Something strange going on with my terminal capture. Data is there, it just does not match logic analyzer. I will have to dig deeper. The most likely reason I can think of is that the 125k Baudrate is not a 'normal' one, so I should not be surprised that it does not work. There was a reason for always wanting the logic analyzer output I guess. But why could I so easily catch them a few days ago? (same HTerm, same setup, same wires, just a different day.)

As always, don't take my ramblings for gospel, if it makes sense, great, if not, ignore.. ;-)

[mstrens]

In the capture of 2.4.6 I see the 3D 01 (request from the receiver) and the reply of oXs.

I saw a bug in version 2.4.6 about the frequency oXs sent the definition of the telemetry fields. I changed this in a version 2.4.7. Perhaps, this help

[KeesBlokland]

In the capture of 2.4.6 I see the 3D 01 (request from the receiver) and the reply of oXs.

I saw a bug in version 2.4.6 about the frequency oXs sent the definition of the telemetry fields. I changed this in a version 2.4.7. Perhaps, this help

Thanks! I think I solved the mystery of the HTerm output. I ran HTerm on my windoz laptop when I made the earlier captures, yesterday I ran it on my main ubuntu system. (wanting to make thing easier for myself.)

Now here it gets interesting: I noticed a few days ago, that when I was 3D printing (octoprint) that I would see quite a few M105 messages in the terminal of VScode. Even when you connect the RP2040, there would appear to be a large number of CR generated, which caused the inventory screen of the RP2040 to be repeated over and over again. After a minute or so it would stop. Now the printer is not connected via USB, it lives on the network. There are a few more 'funny' things happening. Long story short: there is a leak somewhere, which results in messages leaking from one port to another. (this is the simplified explanation.) Software, yeah, always one more bug!

So, right now, 2.5.6 in the box, gps has lock, tx=off, Hterm on windows laptop, Logicanalyzer ready to go. Inventory screen: and a first question:

Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 2 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 3 (GPS_TX = 0, 1, 2, ..., 29) .. snip snip ... Baro sensor is not detected Acc/Gyro is not detected Airspeed sensor is not detected Vspeed compensation channel = 0 First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox (configured by oXs) :GPS is not (yet) detected Led color is inverted Failsafe type is HOLD Config parameters are OK

Does it really not see the GPS? To verify this, I'll need to do the 2.5.2 again, and watch this closely.

But first: power off RP2040, and on again. Logic analyzer: MS-2.5.6-29May.zip HTerm_2023-05-29_07-51-58.log

Need to look at 3B 01 in detail, but it is a reply.

more laters!

[mstrens]

It is not yet clear where is the issue. It could be : 1- in the compilation parameters (I changed my parameters after 2.5.2 in order to get the compilation warnings) 2 - a bug in the way oXs generates exbus frame (just before 2.5.2 I had to fix several issues) 3 - an issue in the way the GPS is configured. In the past I had many troubles to find a way to change the setup of the GPS that was valid for M6, M7, M8 and M10 models.

When you say that 2.5.4 did not work I suspected the second reason. Still looking at the capture, this does not seem to be the reason.

In the capture, I see that the there is no pause in the GPX-TX signal. This is not normal. I had expected some pauses between some packets. It looks like the GPS sent more frames than expected. I should have a look at this. Still I am not sure that this is the reason because I see that it is the same in the 2.5.2 capture.

I would like to be sure I can exclude reason 2 (exbus frame issue). Could you make a test with 2.5.7 where you ask oXs to send also Volt1, Current and consumption. You just have to assign a pin to Volt1 and Volt2. Then just confirm me if the 3 fields are discovered on the handset and if they get a value (even if the value seems wrong because there is no real voltages applied to the pins)

[KeesBlokland]

Here are the results for 2.5.7

Version = 2.5.7 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 2 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 3 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 255 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 255 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 255 255 (V1 / V4 = 26, 27, 28, 29)

Starting again, with everything off, but capture running: MS-2.5.7.zip MS_257_2023-05-29_09-30-09.log

Your 3rd remark is indeed true, but even though the gps keeps spitting out data, it appears to be ok. Had a good flight the other day as you can see below. I had another luxury issue though: Data overload. My pitot sensor did not get a chance to say something. Once I get that hooked up, that problem will be gone, as will the removal of my present sensors. One thing that might be useful is a way to restrict the frequency that individual sensor data is sent. But that's for another day.

[KeesBlokland]

almost. In HTerm capture, I forgot to reset it to 125k. So here are fresh ones.

Note to self: My laptop can be convinced to run at 125Baud, my Dell system does not want to know, so that is likely the real reason why HTerm does not want to play nice on my main system. If I capture at 115200Bd, you get data, but it is NotGood!

output_2023-05-29_10-10-29.log MS-2.5.6-29May1010.zip

It might be a great time for me to learn to do things in python: (page 2 at present) so here's the manual way: output_2023-05-29_1100.log

First thing I recognize in the log : 6F587320 that's 'oXs '. I see around 15 of them in this file. It also means that the last 3 bytes are CRC's (as says the Jeti doc, but always good to see that happen.

Let me know if you want something else! Right now I am trying to decipher the payload of the first message, using exbus.cpp. payload: '0C11A4AD04000019 oXs' using Jeti_Protocol_V_1.07.

[mstrens]

It is not clear for me: with 2.5.7 does the handset discover some sensors (at least Volt, Current consumption) or not?

In a previous post today, you show a list of sensors discovered by handset under "oXs 252". Could it be that you have to delete this sensor as another version of oXs uses the same ID?

I see some blue circles for some fields but not for all. What does it mean? Does the blue circle means that a value has been received?

[KeesBlokland]

Sorry, yes. 2.5.7 discovers all the sensors, that was always working, but the present version does not show GPS values. The values for Volts and Amps are there.

The JetiStudio-image shows 2.5.2 in my plane. The blue circles indicate they are values to be displayed on the map. What I intended to show was that the GPS values in 2.5.2 were there (and about 10 times more then I am used to see). Normally I would not run 2 sets of sensors, so that is not part of the issue. That's just me trying to see how far I can push things, and yes, it is a known fact that mixing 'old' sensors and ex-bus ones leads to data dropouts when you have a lot going on.

So in 2.5.7: all fields are there. Volts and Amps have values. GPS does not show any values.

Hope this narrows it down, and apologies for the confusion I caused.

[mstrens]

OK. So I do not have to look for a bug at the Exbus protocol code but more at the GPS code. I will look at this part.

[mstrens]

It is very strange that your GPS is sending a lot of UBX messages that are not part of the default ublox configuration. There are e.g. about 10 different types of messages of class "01". Did you made a custom config for your GPS or did you used it with another firmware that saved another config. Perhaps you can try to restore the default factory config with Ublox Ucenter software.?

[mstrens]

I think I found the bug in gps.cpp. I had the line calling handling of GPS frames as comment. I put version 2.5.8 on github.

Anyway, it is strange that your GPS sent so many types of frame. Would be good to restore default config

[KeesBlokland]

My thinking at the time was: The GPS on 2.5.2 produced good messages (= proper coordinates on the handset), only updating the software made them go away. In between I make no changes to the config of the GPS in the plane. With the GPS I am working on now, I see the same.

Upload 2.5.2, and GPS (on the handset) shows coordinates, uploading 2.5.>2 and the coordinates are gone. Given that I do use GPS=U to make sure I give it the latest settings, I did not go down the route of checking the GPS settings in ublox again.

Anyway, just did a factory reset, and notice that default, it only shows NEMA messages when in UBlox.

Just noticed you updated to 2.5.8, so I'll try that first ;-)

And bingo, that was it! All GPS-values are there, including the Volt/Ampere.

Version = 2.5.8 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 2 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 3 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 255 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 255 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 255 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 255 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 255 255 (V1 / V4 = 26, 27, 28, 29)

Protocol is Jeti (Exbus) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 1.000000 , 0.000000 , 0.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is not detected Acc/Gyro is not detected Airspeed sensor is not detected Vspeed compensation channel = 0 First analog to digital sensor is not detected Second analog to digital sensor is not detected Foreseen GPS type is Ublox (configured by oXs) :GPS is detected and has a fix // notice this works too. Led color is inverted

and the logs: output_2023-05-29_18-20-20.log

MS-2.5.8-29May1823.zip

I'll have a look at the GPS settings in u-blox now. That turns out to be a bit of a challenge, it looks like it does not keep it's settings after powerdown, I'll have another play with that.

However after a reset, and reconnect to the RP2040, it immediately comes back with the correct coordinates. All in all another happy day, thanks for all the work!

[KeesBlokland]

So far it's happy flying with 2.5.8!

..but I have a Question:

When I look at my logs in Jetistudio, I see that the GPs is providing a lot of data, which I like! However, is there a way to reduce the number of GPS_Sat values, i.e. once I have a lock I really do not need to know every time I have a lock. (in my case) However, the number of values I receive for Pitch and Roll are a lot less then I would like. Ideally I would like them to be at least as often as the GPS-data, even better the same as VSpeed.

Q: Is the amount of data decided by the various sensors? for instance, the Pitch and Roll (MPU6050) does not talk a lot, so you get less data. The GPS is a chatterbox and floods the conversation.

Rex and Rsat data is what Jeti sends as default, which If I remember correct, translates to 100 mSec intervals. The XS1 is a VarioGPS, running on 9600Bd.

ps. If this is interesting enough for others, should I open a new topic?

Regards, Kees

To answer myself: Study the MPU6050 doc!

[mstrens]

When I have time, I could implement a way to allow the user to set up the frequency of each telemetry fields. I already have such a system for FBus (Frsky). The user set the priority of each field and oXs take care of this to full fill the telemetry bandwidth. For Fbus, oXs get a request every X msec (X depends on the number of sensors on the bus). The fields are sorted in one fix priority order but the user can define for each field

• the maximum number of Rx requests allowed between 2 transmissions of this fields. This allows fields with lower priority in the fix list to get a slot.
• the minimum number of Rx requests to respect between 2 transmissions. When previous rule conduct to a situation where there would be nothing to transmit, then the second rule allows to still use the bandwidth to transmit some fields.

I do not know what is the max I can probably do something similar for jeti Exbus.

[KeesBlokland]

Thank you! but don't break things yet ;-)