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

[mstrens]

I am sorry but the jeti exbus protocol has not yet been tested. So I am not surprised it does not work. I am waiting for someone with a logic analyser to make a capture of the exbus signal to understand what is going wrong.

[KeesBlokland]

Hi Michel, I've only just started playing with this project, so I am not fully up to date yet. (trying to wade through RC-Groups and RC-Network posts) I've been testing this part as well, as soon as I get my fresh protocol analyzer (should be there in a few days) I will let you know. Attached doc shows my progress to date. As far as I can see, the prepared output looks ok.

I hope I can contribute to this part of this great project!

regards, Kees

RP2040-no-EXbus-yet.pdf 14th May: The next step: RP2040-no-EXbus-yet-2.pdf

Conclusion so far is that no packets are lost, data is exactly sent to the receiver as it is prepared.

14 May@1300: Just downloaded 3.2.1, no changes made to code. Just a quick compile to see where I am. Serial monitor gives me: exbus rx buffer with wrong check digit Ok, we are getting closer ;-)

[aepub]

It looks like jeti_Exbus protocol is working and we look forward to a perfect solution in the future!

[KeesBlokland]

of course I did not download 3.2.1 for any other reason then to quickly get rid of my own changes! I’ll do a quick writeup about my test setup ( for my own benefit) so that I quickly can repeat what I do. One of the early ‘discoveries’ is that I can simply look at the serial data on the EXbus with a standard usb-serial dongle. No real need for a logic analyzer.

[aepub]

I am using JETI DC16 and RX9, etc. If Ex Bus can function normally, it would be great and I look forward to it very much.

[KeesBlokland]

Me too, DC-16/DS-14. Only problem is that the R9 does not have a EX-bus out. At least my vintage 12 year test receiver does not have it, only standard slow. For testing I use an Rex10 at the moment. I’m doing a lot of glider-tugging, and at 500 meter altitude, it gets very hard to see the attitude of the plane. My ultimate goal is to get faster/better feedback of pitch and roll. Using a gyro system is not really an option, because you really don’t want that to take control, too many scary thing could happen! I already use a pitot airspeed indicator to keep me at the preferred speed, but more and faster data is always better. Also thinking it would be cool to take the data output from the Tx and wire that up to a display (thinking of Jetistudio in live mode for starters). But as always in code, it takes time for me to figure out what is happening, since I am not a software guy.

[aepub]

Fortunately, my receiver is RX9 or RX12, which can be set to Ex Bus or UDI mode without having to purchase a new transfer machine. The current Oxs test version firmware does not have sensor display data in exbus mode and can only be in UDI mode. The ones I fly the most are gasoline or methanol aircraft models, and recently I have also flown electric ones. The reason for paying attention to Oxs is also that it allows me to see some flight data, such as the battery voltage used for the rudder and the power battery voltage of the active electric aircraft model, to avoid accidents caused by power outages. At the same time, as gasoline or methanol engines are prone to stalling, I have recently been trying to determine whether the RPM function of Oxs can be used to detect the engine speed. When it falls below a certain threshold, the throttle can be adjusted in a timely manner to prevent damage caused by stalling. Of course, this is only an idea, and can it be tested.

[KeesBlokland]

I am at the point where I need to acquire some serious debugging skills. I have been trying to get some help from ChatGPT, and even though that is fun, it does not always give correct answers. (no surprise there, it is a text tool trying to do things it does not understand) However 'we' managed to create working code to process the CRC stuff so that it gets to the 'Send Telemetry' function. But there it stops for the moment.

RP2040-no-EXbus-3.pdf

[mstrens]

In order to debug, I use 2 ways.

• first I add some "printf" commands in the code in order to get information on the PC (via USB cable). This allows to know if the program run into some part of the code. It also allows to know the value of some variable and so to know if it is normal or not.
• I use a logic analyser to look at the signals received and generated by oXs. This is important e.g. on a bidirectional bus (like Exbus) to check if the replies of oXs fit into the time windows expected by the protocol (avoiding e.g. conflict between an oXs reply and the next request/data sent by the receiver.

I think that oXs can read the data sent by the receiver because:

• oXs does not give debug messages (via printf) that the CRC of the received frames is wrong
• oXs gives debug messages with the content of the telemetry frame it created.

If the Tx does not give telemetry data, it means that there is a bug

• or in the content of the telemetry frames being generated
• and/or in the timing those frames are put on the exbus. The best tool to check this is a logic analyser.

[KeesBlokland]

Thank you, effectively I use those 2 methods as well, I usually look at both the data on the logic analyzer and compare it to what I see on the USB dongle. I see that the data on the USB always matches the data on the USB dongle. Therefore I mostly use the USB dongle for logging the data, it is a bit more convenient.

I do use print statements as much as I can. Example:

bool exbusProcessNextInputByte( uint8_t c){ // check if valid printf("Process incoming byte: 0x%02X\n", c);

I see the incoming packets. The output of HTerm (USB dongle) and the output on my terminal right now is:

2e e0 2e e0 2e 92 24 //this is the start of the terminal output. I removed some cr's in the terminal output for readability.

3d 1 8 25 3a 0 c7 6d // my telemetry request, as seen on the input to exbusProcessNextInputByte

3e // next 3 lines as they appear on terminal. Process incoming byte: 0x3E exbus rx buffer with wrong check digit 3 28 25 31 20 //end of terminal output, with removed cr's for readability.

Some how it consistently starts processing the next 3E sequence, but skipping the 3D sequence.

Exactly the same happens when I enable the Simulate RX_EXbus code.

Sofar I have not seen any evidence that it even starts to use exbusCreateSendTelemetry(); from: printf("calling exbusCreateSendTelemetry\n"); exbusCreateSendTelemetry();

My next step is trying to find out why it skips the 3D0108 but tries to process the 3E sequence. And yes' I'll look at the logic analyzer output, to see at what stage in the message the 3D01 appears, compared to the 3E etc.

an interesting problem for sure!

..but probably I am wrong in assuming that printing the byte right there works. Need to do that differently. Need to catch it before it gets send to exbusProcessNextInputByte()

tomorrow is another day ;-)

[mstrens]

When I:

• uncomment the line #define SIMULATE_RX_EXBUS and
• add printf("exbus creating tlm frame\n"); at the beginning of function exbusCreateSendTelemetry()

then I get on USB: exbus decoding Rc channels exbus creating tlm frame exbus decoding Rc channels exbus creating tlm frame exbus decoding Rc channels exbus creating tlm frame exbus decoding Rc channels exbus creating tlm frame

This shows that the 2 types of frames coming from the receiver are recognized by oXs

[KeesBlokland]

Strange indeed!

Tomorrow morning I’ll try your published version for testing, just to exclude the possibility of me building buggy code.

[KeesBlokland]

Good morning all. I am looking at the Logic analyzer input (Ex-bus), using the unmodified oXs.uf2 as published here. After acquiring a bit of data, stop the Tx, and start looking for 0x3D packets.

• First thing to notice is that the Telemetry requests arrive exactly every 10 mSec. (green marker 1)
• After the the complete request has been received, you see the 4 milliSec gap, where TLM data could go. (Between purple marker 2)

And then the first byte that arrives is 3E, which sort of matches my earlier observation. (Process incoming byte: 0x3E)

Next: build code again, and verify that my build matches what I see here. when it matches, start adding debug print statements.

File captured with Logic 2 from Saleae: Ex-bus-tlm_req.zip

[KeesBlokland]

Hi, when you say: uncomment the line #define SIMULATE_RX_EXBUS and add printf("exbus creating tlm frame\n"); at the beginning of function exbusCreateSendTelemetry()

then I get on USB: exbus decoding Rc channels exbus creating tlm frame

With SIMULATE_RX_EXBUS enabled, I only get 'exbus rx buffer with wrong check digit' on my terminal.

my .uf2 and exbus.cpp: oXs.zip exbus-cpp.zip

[mstrens]

do you use the version in test branch?

[mstrens]

When you activate the simulation, oXs should not be connected to the receiver (otherwise there could be a merge of simulation and receiver signal)

[mstrens]

perhaps that tlm did not work because oXs dis not sent reply to jetibox request. In a new version 2.4.1 in test branch, I now added support for jetibox frame.

Hoping it could help.

[aepub]

Downloaded 2.4.1, mode selection Jeti Exbus remote control cannot find the sensor on 2040. After connecting to the serial port, this message keeps displaying!

[mstrens]

Sorry, in 2.4.1 I forgot to remove the option to simulate a jeti RX. This could explain the messages (conflict between receiver and simulation). I now put version 2.4.2 on github where I removed this simulation option.

Perhaps is it ok now

[KeesBlokland]

Just installed your 2.4.2 uf2 version on my board. When tx is on, I see the following two messages in the VSCode terminal.

exbus decoding Rc channels
exbus creating tlm frame.

but no actual messages on the ex-bus yet.

When I compile the code, the result ( after disabling Sim stuff) after installing my uf2: Tx = off

Rx=
exbus rx buffer with wrong check digit.

Q: I am using Visual Studio Code v 1.78.2 and GCC 12.1.0 arm-none-eabi. However, even though the code compiles without errors, I do not seem to be able to get the same results from my uf2 that you get. Can you share your setup?

Q: The topic seems to be closed, is there another place we can continue the story?

Enclosed the capture file I just made with your 2.4.2 uf2:

ex-bus-2.4.2.zip

[mstrens]

I do not know why thye topic was closed. I reopen it.

I am also using VS code 1.78.2 but for GCC I am on 10.3.1 (this is probably the version that the windows rapsberry installer has installed). The 2 messages that you get are the same as the one I get (but as I have no Jeti TX/RX I have to activate the simulation with the #define). Take care not to activate the simulation when oXs is connected to the RX.

With the version you compiled yourself, when the TX is on, do you get the same messages as with my version? When the Tx is off, I expect that the RX set the bus in High impedance and it could be that oXs get noise (= dummy char)

May I suggest making first tests with a config that only activate Volt1 (so you can set the VOLT2, ...I2C and GPS pins on 255). Compared with the version non EXbus, the EXbus version can sent more than 15 telemetry fields. For fields having an index above 16, I use a special way to fill the data. I did not find this way in the doc but in the code made by other people. I expect it is valid but I am not 100% sure. Another difference between non Exbus and Exbus is the fact that in Exbus I have some gaps in the sequence of field index. Again I expect it is valid because I saw other code that are build in the same way. If needed, I could make a test version that would only sent one tlm field with an index = 1 (just to be sure)

I did not yet looked at your capture. I will do it in the next hours.

[mstrens]

I put on github a version 2.4.3 where:

• I send the tlm frame faster after the request
• I send the list of fields more often.

Not sure it will help!

[aepub]

Is EXbus still in the testing phase? I used 2.4.3, the version you compiled, and RP2040 showed a red indicator light. After compiling with vSCODE myself, RP2040 showed a green indicator light instead of the normal blue indicator light.

[mstrens]

The jeti EXbus protocol is still in testing phase. As far I know the Tx does not discover the sensors and I do not know why.

I also did not really take care up to now about the color of the led for Jeti Exbus protocol. I would have to check this part. of the code. I still expect that the led should blink (after the setup delay). This is done to show that the program is still running the main loop (and so is not blocked somewhere). Please note also that some users got RP2040-zero modules with a led that has 2 inverted colors. To take care of this, it is possible to activate an option in config.h to invert the colors.

[KeesBlokland]

re led: it’s only correct when you change the setting in config.h after that, the behavior is correct.

This is valid for my Waveshare board, so you need to play until you get the correct colours.

[KeesBlokland]

on 2.4.2: I still see that the first byte processed is the 3E, not the 3D. Don’t want to post too much noise, so I will try to get to the bottom of that.

If it is helpful I can post a longer capture of actual exbus traffic. A couple of meg should be no problem.

Let me know if you need it.

just a wild thought: the 3D01 sequence is inside a longer packet. The 3E part is the start of the next packet. Could that be the reason, it has to look inside that whole string to find the 3D01 etc just roughly counting, 3D is approx 30 odd bytes after the 3E starting packet.

Need to check that laters! regards, Kees

[mstrens]

In Exbus protocol, the Rx sent 2 frames after each other. The first one starts with a 3E 03. It provides the Rc channels. It is (often) immediately followed by a 3D 01 that is the telemetry request. oXs replies to the 3D 01.

Each frame sent by the receiver has a packetId. It is strange that this packetId does not change in most case. I expect that the receiver reuses the same packetId as long it does not receive a valid reply.

I will check again the way I fill the frame for a reply. If I do not find the bug, I will probably make a version where I just sent dummy frames copied from a official jeti sensor.

Do you have an official Jeti sensor? If so, I would like to get a capture with a logic analyser of the exbus signal to compare with what I am sending.

[mstrens]

I put on githu a version 2.4.4 where I change the position of the first char used to calculate a CRC inserted in the telemetry frame. I hope this solve the issue. Let me know.

[aepub]

Version 2.4.4, able to display sensors on Jeti's receiver! Excellent!

But on the serial terminal, this information is constantly displayed!

---

Because using the files in your zip file package, the LED displays red. After compiling with VSCODE myself, it displays green, but sensor information cannot be displayed on Jeti. Is it related to the compiled version? My sensor cannot function properly with Jeti remote control GCC10.3.1 arm non eabi, VSCODE 1.78.2

[mstrens]

Thanks for the feed back. I now put version 2.4.5 on github in order to

• remove the debug messages
• sent the field names less often (once every 256 frames instead of once every 3); this allow to sent more often the fields values. Note : I do not understand why you can't compile yourself. It is strange.

[aepub]

1. Using the version you compiled, the sensor can display RP2040 flashing red, but it will flash once every 1 second on the remote control display screen. The time to find all the sensors in the remote control is also very slow, which takes about 1 minute;
2. Using my own compiled version, the sensor cannot display properly on the remote control.

[Satcomix]

1. Using the version you compiled, the sensor can display RP2040 flashing red, but it will flash once every 1 second on the remote control display screen. The time to find all the sensors in the remote control is also very slow, which takes about 1 minute;

   2. Using my own compiled version, the sensor cannot display properly on the remote control.

Hello aepub, I think you have a problem with the folders. I have attached a complete .txt printout of the build folder and running a Ver.2.4.5 build from my PC with Win10Pro Maybe it helps. Best regards, Torsten VSCode_oXs_Build.txt

[aepub]

My compilation environment is installed by default（ https://github.com/raspberrypi/pico-setup-windows/blob/master/docs/tutorial.md ）The code for the main branch can be used normally after compilation, but the only difference is that the current test compilation is different from yours, and I don't understand why. The attachment shows me using vscode to open the folder oXs on RP2040 test and compiled output text information. aepub-build-oxs.txt

[KeesBlokland]

Hi Michel, just put 2.4.5 on the chip, fired up the tranny and see there: magic!

looks like you did it!

And thank you for adding the roll and pitch values, that is going to be so much fun for me!

and a capture file: ex-bus-2.4.5.zip

..and compiling with GCC 10.3.1 arm-none-eabi works too! (for me at least) So for anyone compiling with GCC 12 and having strange problems, try 10.3

A green blinky light, I can see where I live, man I am so happy!

Enclosed a reversed LED uf2, in case someone can use it. oxs_reversedled.zip

[Satcomix]

My compilation environment is installed by default（ https://github.com/raspberrypi/pico-setup-windows/blob/master/docs/tutorial.md ）The code for the main branch can be used normally after compilation, but the only difference is that the current test compilation is different from yours, and I don't understand why. The attachment shows me using vscode to open the folder oXs on RP2040 test and compiled output text information. aepub-build-oxs.txt

Hello aepub, I see some differences to my SDK build folders. I build on C:/ and save to C:/ When you install Pico setup, on C:/User/Documents/Your_Folder_CMake_RP2040. This folder contains 4 folders: 1: Your_Folder_oXs_RP2040, 2: pico-examples 3: pico-extras 4: pico playground Normally in 1: Your_Folder_oXs_RP2040 you have 4 folders. 1: .vscode 2: build 3: oXs_on_RP2040-main 4: oXs_on_RP2040 test In this folder are the unzipped copys of the GitHub -test or -main .zip folder.

In 4: oXs_on_RP2040 test you have the folders: vscode, build, oXs_on_RP2040 test br, Torsten

[aepub]

My vscode is installed by default.

For the Oxs files, I created a separate Oxs folder on the D drive, with main and test versions, and compiled and stored them in separate folders according to different version numbers.

Do you want to place the Oxs folder in the pico examples folder?

I compiled the main version of Oxs and the previous test version very normally, and this strange phenomenon occurred this time.

[mstrens]

I just made a small change in order to reduce the delay to let the handset discover the name of all sensors. It is in version 2.4.6

[Klippeneck]

Hello mstrens, first of all, thank you for your work on the sensor. Tested today with SW2.4.6, equipped with MS5611 and Beitan GPS 220 with Jeti REX 10 and DS 16II, sensor configured on EX bus. Logon works, telemetry data also comes. After the GPS fix the GPS values also come, only the GPS lat is not stable and jumps arbitrarily. Would a log file be helpful?
Jürgen

[Klippeneck]

The values for Lat. jump between -8,175deg and 687,878,154deg.

[aepub]

1、I used another Win10 computer that had successfully compiled Oxs before and compiled oXs again on RP2040 test, Jeti remote control cannot find sensor! 2、 I attempted to remove the current compilation system vscode and restart pico setup windows. However, the downloaded version of V0.5.1 encountered an error at the end of installation: https://github.com/raspberrypi/pico-setup-windows/releases/download/v0.5.1/pico-setup-windows-x64-standalone.exe. “Installation of Visual Studio Code failed.Please install it manually by downloading the install from:https://code.visualstudio.com/"

So choose V0.5.0 version and install it successfully. https://github.com/raspberrypi/pico-setup-windows/releases/download/v0.5.0/pico-setup-windows-x64-standalone.exe. And add oXs on The RP2040 test folder is located in C: ProgramData Raspberry Pi Pico SDK v1.5.0, along with pico examples. However, after compiling and uploading to RP2040, the sensor still cannot be found on the JETI remote control.

However, using the version downloaded from Github is normal.

How strange!

[mstrens]

@Klippeneck I do not see immediately why GPS lat jump. I put a version 2.4.8 on github that should sent debug messages to the USB. There should be 2 types of lines:

• one with the original GPS lat value from the Ublox and the other with the GPS lat as formatted for Jeti
• the other with all telemetry frames (txt or data). Those lines contain only an extract of the frame (txt or data part) Looking at the message will perhaps help to find the bug. Can you try it and send me a copy of the messages (at least after GPS got the fix)

[Klippeneck]

Hello mstrens, I have installed SW 2.4.8, but when I enter FV for a fix, I get the following: fv processing cmd Cmd to execute: FV

GPS Latitude = 48.0543008 degree GPS Longitude = 8.7253440 degree GPS Groundspeed = 6 cm/s GPS Heading = 243.750000 degree GPS Altitude = 82623 cm GPS Num sat. = 107 GPS Date J M A = 22 5 23 GPS Time H M S = 17 9 52 GPS Pdop = 230 GPS Home bearing = 64 degree GPS Home distance = 21 m Vspeed = -2 cm/s Baro Rel altitude = 72 cm Gps cumulative distance = 30 Vspeed compensation = 1.10

I am not entirely clear about the USB, is the sensor operated on the receiver for this purpose? and in parallel via USB of the RP2040 with a terminal program the output is recorded on USB? I would then also have to supply the sensor with voltage via USB.

[Satcomix]

Hello Klippeneck, The command FV in terminal shows you the FieldView of the telemetry fields, that are transmitted from the oXs_RP2040 to the handheld/transmitter. FV=FieldView not GPS Fix. br, Torsten

[mstrens]

When RP2040 is connected to PC via USB, I would recommend (not sure it is really required) to power the RP2040 (and sensors) only via USB. So I suggest to disconnect the red wire from the Exbus JR connector.

[Klippeneck]

Hello mstrens, Frame= 1 11 0 40 Frame= 1 11 0 40 Frame= 61 69 0 1 11 0 40 Frame= 61 69 0 1 11 0 40 lat orig=1ca47e84 jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 7 20 41 0 0 51 6 3 1 1 11 0 40 Frame= 1 11 0 40 Frame= 1 11 0 40 Frame= 12 19 41 6c 74 6d Frame= 61 69 0 4 12 2 0 20 1 11 0 40 lat orig=1ca47e84 jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 a 20 41 0 0 51 6 3 1 1 11 0 40 Frame= 1 11 0 40 Frame= 1 11 0 40 Frame= 61 69 0 1 11 0 40 Frame= 61 69 0 1 11 0 40 lat orig=1ca47e84 jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 8 20 41 0 0 51 6 3 1 1 11 0 40 Frame= 1 11 0 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e81 jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 7 20 41 0 0 51 6 3 1 4 12 2 0 20 1 11 6 40 Frame= 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 11 33 56 73 70 65 65 64 6d 2f 73 lat orig=1ca47e83 jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 2 20 41 0 0 51 6 3 61 69 0 1 1 11 6 40 Frame= 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 1 11 6 40 lat orig=1ca47e86 jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 51 6 3 61 69 0 1 1 11 6 40 Frame= 31 3 20 41 0 0 4 12 3 0 20 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e8a jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 4 20 41 0 0 51 6 3 1 1 11 6 40 Frame= 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 0 19 6f 58 73 20 lat orig=1ca47e8c jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 2 20 41 0 0 51 6 3 1 4 12 2 0 20 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e8d jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 3 20 41 0 0 51 6 3 1 1 11 6 40 Frame= 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e8e jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 3 20 41 0 0 51 6 3 1 1 11 6 40 Frame= 1 11 6 40 Frame= 4 12 3 0 20 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 1 39 47 70 73 20 4c 61 74 b0 lat orig=1ca47e8d jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 5 20 41 0 0 51 6 3 1 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e8c jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 1 20 41 0 0 51 6 3 1 1 11 6 40 Frame= 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 4 12 3 0 20 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e8c jeti=300cb6 Frame= 19 b6 c 30 0 29 18 aa 8 20 31 2 20 41 0 0 51 6 3 1 1 11 6 40 Frame= 1 11 6 40 Frame= 1 11 6 40 Frame= 61 69 0 1 11 6 40 Frame= 61 69 0 1 11 6 40 lat orig=1ca47e8d jeti=300cb6

[mstrens]

The debug messages seems OK. The first frame line following a lat orig line contains always the same value B6 C 30 0 (that matches the jeti value - in reverse order).

So, I do not understand why the latitude value displayed on the TX changes.

[KeesBlokland]

The debug messages seems OK. The first frame line following a lat orig line contains always the same value B6 C 30 0 (that matches the jeti value - in reverse order).

So, I do not understand why the latitude value displayed on the TX changes.

..maybe we are pushing the limits of what Jeti can handle! But before jumping to that conclusion, it’s time for more debuggins. Weather is lousy here, so it’s a good day for it.

[mstrens]

you can try different things:

• change the parameters via usb commands to let oXs transmit only GPS data (set volt1,..SCL, SDA on 255)
• let oXs transmit all fields with fixed values using the commands FVP and FVN. Note: please use new version 2.4.9 when you use those commands because I just fixed a bug (protocol was changed to J when those commands where used)

[KeesBlokland]

Here you go: Version = 2.4.9

with only GPS:

devttyACM0_2023_05_23.08.57.10.775.zip ex-bus-2.4.9.zip

and trying with FVP. Note that the monitoring output stops after spitting out one long Frame=1 a1 .. line. After Stopping and Starting the monitoring, you see the Frame= again. See the attached log below.

devttyACM0_2023_05_23.09.09.06.901.txt

In my last video I made (need to shorten it) it show not only the Lat jumping. I will remove all unnecessary sensors and just do only GPS display. (just to be sure to be sure).

video was 2.4.8, making a fresh one now, but you can hopefully see what happens. It is not only the LAT (it was originally only LAT that was jumping. Maybe another thing to note: Before the GPS had a lock, it would show blanks in LAT/Sat but 0.00.00 in LON. ) https://github.com/mstrens/oXs_on_RP2040/assets/1756333/104e7b11-3b8f-4869-bc93-cc819b3fa837

[mstrens]

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?