openrcforums

Due to a lack of enough hardware timers on the Atmel processor, I'm using a PWM channel to provide the timing for sending the data. I was using a default high time of 2.5mS and a period as required for the requested rate. For 500Hz, 2.5mS is clearly too long as the rate requires 2.0mS period. I chan...

I'm not sure why it behaves like that. I can see from the log file that it isn't getting into synchronisation, as the 250Hz timing does.
The attached file may do that correctly.

I'm working on something to do with LUA scripts, so the file has got bigger!

Mike

Please try this one, I found a reason why the last one would do something wrong at 500Hz.

Mike

Here is a test version that might work at 500Hz on ELRS, then again it might not work properly at all as I haven't been able to test it!

Mike

Attachment removed as it didn't solve the problem.

There is probably a problem trying to run at 500Hz on the 'Pro, I think the timing I currently have doesn't support it and ends up defaulting to 32.768mS instead of 2mS.
I will have a look, but I don't have any Crossfire of ELRS hardware I can use to test any changes.

Mike

From the main screen, if you go UP LONG, then RIGHT to the STAT2 screen you can check the "Mixer Rate", it should show 500. If it does, then I would suspect the gimbals. If they only update every 33mS, then the filter option won't have any effect as all filtering will happen within the 33m...

I've now managed to get FPort2 working (115200 baud) on both 16MHz and 8MHz processors. I've coded some interrupt routines in assembly language to make them fast enough to "bit-bash" the serial data at 115200 baud. In general, I do have some questions on the use of a GPS sensor. This appea...

I've just got a version of the openXsensor working using FrSky FPort1. I'll now see if I can get FBUS(FPort2) working as well. The downside is I've needed to make use of the hardware UART in order to read all the FPort/FBUS data (41 bytes) that is sent at 115200 baud. This means you are not able to ...

What firmware (and version) do you have on the 'PRO, erskyTx or openTx?

Mike

I found that Ethos version 1.4.3 does NOT work with ErskyTX version r12. I had dual boot working with Ethos version 1.4.1 but it appears that something is different with the .bin file with ver 1.4.3 that causes my X20 to do nothing with I tried to boot ethos, it would still boot ErskyTX just fine. ...

I've posted R13 of erskyTx for the X20.
I've improved many menus for use with the touch screen.

Mike

You could try the ELRSv2.bas, and add the change shown a few post back. This then appears to work with ELRS V3.

Mike

Should work OK.

Mike

Is your X9Lite the standard version or the S/Pro version? I just did a test on my X9LiteS with an external XJT-Lite and was able to bind to a D8R-IIPlus and a X8R (running UNI firmware) with no problem. The (test) erskyTx firmware I'm running may have some changes related to the XJT-Lite. I'll check...

What version number is reported in the erskyTx "version" menu?
I assume you mean you cannot choose a XJT-Lite module, but can select PPM, Multi etc.
Have you changed the Type to "D8" for the D8 protocol?

I'll check on my X9Lite.

Mike

Both my prototype X9D and prototype X9D+ have extra connections made to the JTAG pads JTCK and JTMS, and erskyTx includes options in the hardware menu to use these as extra switches called PB1 and PB2.

Mike

If you have the 9Xtreme upgrade board, then you need to use eepskye (not eepe) to connect to the Tx. Check your mixer configuration and see if the trim checkbox is not ticked in some of the mixes. If a trim is not required in any mix, then the trim switch doesn't move the display, and you may then u...

Why a 5 second delay in the motor starting?
Sounds as though the speed controllers are using different centre positions. I would try changing the sub-trim (in the limits menu) on one of the motor channels to adjust the centre output position.

Mike

Yes, an upgrade board would be necessary to use that module, unfortunately, I don't believe any such boards are available any more.
erskyTx (er9x for ARM processors) is available for the Taranis (and many other FrSky transmitters).

Mike

I've just fixed the links so they should work now.

Mike

andrewju wrote: ↑Fri Dec 23, 2022 6:10 pm Hi Mike,

That link leads to a 'file not found' (and also for the regular X-Lite).

Ahh, a typo!
Copy the link, then use it with the 'L' change to 'l' (lower case).
I'll fix it at some point.

Mike

On http://www.er9x.com/ there is a version of erskyTx for the X-LiteS (rev 223).

Mike

Smart Port needs 57600 baud and "half Duplex" so with the Tx pin connecting to the SPort signal. The SPort is also inverted, and there is a comment in your PNG file saying you may need external inverter hardware, although the options also imply there are invert options for Tx and Rx signal...

The main problem is you are using Pixhawk passthrough telemetry. There just isn't enough flash space in the '64 to be able to process that. Since you have RSSI working, then the Smart Port from the R9 module is working. I tested the same firmware with a R9 Rx and a FrSky vario on the SPort and got t...

Try changing the UsrProto to FrSky, not FrHub.
I'll see if I can check thing out later, I don't have a '64 9X any more, but can try the '64 firmware on a '128.

Mike

I just downloaded X20-EU.zip (1.4.3) and used the .bin file to create the composite file and flash this to the radio. This all worked fine and both Ethos and erskyTx ran OK. I haven't been updating my bootloader (or used suite), so I'm still using quite an old bootloader. I'll look to update the boo...

Failsafe is deactivated as soon as a valid packet is received, no waiting time.

Mike

You appear to have R820 on your Tx. R821 has been released. This may have the R9M type in it.
Try D16 and see if the SPort telemetry does work.

Mike

In the Protocol menu, after having selected XJT, check if you are able to set the Type to R9M. With the ATMEGA64, there is limited support for the R9M module, there is not enough flash space for full support. For the Telemetry, it should work if you connect the SPort signal on the back of the module...

The SPort protocol document is released by FrSky under a NDA, so we cannot publish it. You do (probably) need to look at the c/cpp code available on Github for erskyTx, openTx, edgeTx or the multiprotocol module to pick out the data scaling for individual sensors, and the specific checksum calculati...