XJT module and 9x

[cae]

I am trying to get the PXX protocol to work with an XJT module in a 9x and an X8R receiver.

I have tried with a telemetry modified stock board (telemetry disconnected from main board for the moment), and a Sky9x board, with the latest versions of both er9x and opentx but can't get any servo response with PXX selected.

Has anyone else tried this and made it work?
Is it indeed even possible with the PXX code in the current firmware?
If it is workable, how do you set the receiver number?
Is there code in er9x or opentx for that matter, to decode smartport data with the 9x? (Assuming the SmartPort pin on the module is interfaced correctly to the board)

Sorry for all the questions, any help would be appreciated.

Regards
Colin.

[Kilrah]

Did you self-compile the firmware? PXX is not enabled yet in official builds (no option for it in c9x).

openTx should have "close-to-working" PXX code, but untested and probably buggy on other platforms than the Taranis because nobody in the team received an XJT to test with.
About telemetry, SPORT code exists of course but is not used on the 9x at this point for the same reason.

In ER9X I believe the implementation is still the one of the "preliminary" PXX spec, I don't think Mike updated it to the final spec at this point.

[cae]

Hi Kilrah,

No, I used the precompiled versions.

I sort of expected what you are saying to be the case, so I am preparing to compile now.

I was going to start with er9x as that's the one I have done the most with, however from what you are saying it might be better to try openTx, maybe Mike might respond and confirm the er9x implementation.

I will have a look at the SPORT code in the Taranis version and see if I can get something to work on the 9x.

Many thanks for your post, I appreciate it.

Regards,
Colin.

[MikeB]

If you have done the telemetry mod to the 9X (stock or sky), be CAREFUL with pin 2 of the 5-pin module connector.This drives an RS232 output level signal (+/-6V to 9V). The XJT module, pin 2 drives a herstbeat signal out. You may damage the XJT with the RS232 signal driving in!

Er9x does still only have the early version of PXX implemented. This does work with a re-programmed DJT module. As Kilrah says, we don't have plug in XJT modules so have nothing with which to test any changes.

Mike.

[cae]

Hi Mike,

Yes, the telemetry mods have been done on both boards, but I have not connected pins 2 and 5 of the XJT to the main board as I was aware of potential conflicts.
I also detected the signals on pin 2 and 5.

I had checked out the early PXX implementation on DJT, and was hoping that would also work with XJT, but apparently there have been changes to the protocol.
Without more information on the current implementation it will be rather difficult to get it to work on er9x, so I will try openTx, Kilrah seems to think it might work, if so I might be able to use some code from openTX in er9x.

Do you have any information on the heartbeat that you can reveal, or is it still restricted.

Thanks for your post, much appreciated.

Regards,
Colin.

[Kilrah]

AFAIK heartbeat isn't implemented. If you have a scope you could check if there's something coming out on pin 2, but on the Taranis' internal module there's nothing with the current module firmware. The idea was for the module to send a pulse on there at every RF cycle so that the radio could sync the moment it sends out new data optimally.

Regarding PXX, on the Taranis we send info such as RF protocol, failsafe data, bind and range check commands through PXX. The XJT has DIP switches for that, which are obviously required when operating in PPM mode, but we don't know exactly what happens when driving it with PXX. Logically what is set in the PXX stream would override the switches, but we don't have confirmation. And if it does then some work is needed as the 9x UI does not have menu entries to configure those settings yet.

[cae]

Hi Kilrah

I have checked pin 2 and it appears to have rubbish on it which is why I asked the question.

Certainly more work involved in using er9x at the moment, so I will try opentx first and see how that goes.

Thanks for the info.

Regards,
Colin.

[jhsa]

I think it is also not working on opentx??

[MikeB]

I'll see what I can do on ersky9x to start with. I don't think anyone is actually using PXX to a DJT, in wasn't generally released.
I might be able to test using a prototype XJT module from the Taranis.

The biggest impact on er9x on a stock board (with an M64) will be to use up extra flash but probably worth it for the extra functionality.

There are two areas to consider:
1. The PXX output protocol. This should not be too bad as lot of the PXX stuff is already in.
2. The SPORT telemetry data. On stock, this may cause problems as it runs at a higher baud rate (57600) and may impact the quality of the PXX output which has to be bit-banged on interrupt. The SKY board and the Taranis have hardware driven PXX outputs. There will also be an impact on the amount of flash used as the SPORT processing will be larger that the original serial.

Mike.

[jhsa]

Thank you Mike..

João

[cae]

I think it is also not working on opentx??

Hi jhsa

I have found it does not work on opentx vers from the compile server, I was hoping it might work if I compile locally. I am about to find out.

Thanks.

Colin.

[cae]

I'll see what I can do on ersky9x to start with. I don't think anyone is actually using PXX to a DJT, in wasn't generally released.
I might be able to test using a prototype XJT module from the Taranis.

Mike.

Thanks Mike that would be great. Let me know if I can help with testing etc.

Colin.

[Clivew]

I'll see what I can do on ersky9x to start with. I don't think anyone is actually using PXX to a DJT, in wasn't generally released.
I might be able to test using a prototype XJT module from the Taranis.


Mike.

I did try it Mike using the info you posted yonks ago. At that time it didn't offer anything extra
in terms of latency/model match I think? But it certainly worked fine!
I labelled the DJT, but not the D8R that I upgraded the firmware on,
can't remember which receiver it was now!

Clive

[cae]

A quick update.
I have compiled openTx with PXX for the standard board. It sort of works, the pulse width at neutral is 2.172ms and will reduce to 1.8ms with stick movement, will not increase.
Model match does appear to work.

Have not tried on Sky board yet, I will see if I can find a solution (or at least a reason) for the standard board first.

Colin.

[MikeB]

The original PXX was centered on a value of 2250, for 8 channels only.
The XJT PXX is centered on 1024 (first 8 channels), or 3072 (second 8 channels).
Only 8 channels are sent in each PXX packet.
2250-1024 = 1226 (units of 0.5uS?)
So this is 613uS offset.
1500+613 = 2.113mS, about what you are seeing!

Mike.

[Kilrah]

Yep, this matches what would happen if the protocol was still the old one.
It should be as easy to fix as replicating what's in pxx_arm.cpp into pulses_avr.cpp.
On sky9x the ARM file should be the one that's included, so it should already be OK.

But again some UI elements are missing.

[cae]

The original PXX was centered on a value of 2250, for 8 channels only.
The XJT PXX is centered on 1024 (first 8 channels), or 3072 (second 8 channels).
Only 8 channels are sent in each PXX packet.
2250-1024 = 1226 (units of 0.5uS?)
So this is 613uS offset.
1500+613 = 2.113mS, about what you are seeing!

Mike.

Thanks Mike,

Yes that is pretty much what I am seeing, now I understand why.
I am looking through the code at the moment trying to get a feel for the protocol before changing any code. (sure would be nice to see the protocol specs)
I see Kilrah has also posted, and I will look into his suggestion.

Colin.

[cae]

Yep, this matches what would happen if the protocol was still the old one.
It should be as easy to fix as replicating what's in pxx_arm.cpp into pulses_avr.cpp.
On sky9x the ARM file should be the one that's included, so it should already be OK.

But again some UI elements are missing.

Thanks Kilrah,

That was my first thought, but as I said in the post to Mike above, I would like to understand the protocol a bit better before changing any code.
As far as the UI elements, I will get basic control working first and then and then look at adding the missing UI elements.

I am just moving all my models across to another TX, so I can work on the Sky9x board, as this is the TX I normaly fly with.

Colin.

[cae]

Another update.

Quick fix to get first 8 channels working with 1.5ms centre, with range from 0.998ms to 2.01ms, using opentx and 9x board.

In pulses_avr.cpp change function "uint16_t scaleForPXX(uint8_t i)" as below

uint16_t scaleForPXX(uint8_t i)
{
// return channelOutputs * 3 / 4 + 2250 ;
return channelOutputs * 3 / 4 + 1024 ; //cgk 19-08-13, to give 1.5ms centre
}

Appears to work fine, no strange behaviour detected yet. Will continue testing if no problems found I will fly with it Wed.

Colin.

[Kilrah]

Yeah that should do it, you may have a tiny scaling error but shouldn't be bad (exact factor is as in pxx_arm.cpp, 512/682=0.75073).

[cae]

Yeah that should do it, you may have a tiny scaling error but shouldn't be bad (exact factor is as in pxx_arm.cpp, 512/682=0.75073).

Yes I noticed that, not too worried at this stage I don't think that error will be noticable, working on getting second 8 channels working first, then on to telemetry. That should be fun.

[cae]

I flew the XJT with X8R Rx with PXX modified opentx and stock 9x board today, as expected it performed flawlessly.

After Mike saying he thought that the stock board may be a bit slow working with SPORT telemetry, I compiled a version of opentx with PXX for the Sky9x board, but ran into a slight problem.
Because the firmware overrides the switches on the XJT, as Kilrah suggested it might, if I put the module into bind mode manually, the firmware turns it off again after about three seconds, too quick to bind the RX so not possible to see if it works.

So it looks like I need to add code to the firmware to allow bind and range check modes ( and probably failsafe too) to be set from menu items.

Colin.

[jhsa]

Are you also doing it for the stock board? I mean the range check and failsafe?

João

[MikeB]

Try turning the Tx on with the throttle not idle, but with the module in bind mode. While the Tx is waiting for the throttle to be idle, it doesn't send any pulses to the module.

Mike.

[Kilrah]

Also, you can put the receiver in bind mode, THEN put the TX module in bind mode, and it will bind instantly. So no problem with the 3 secs.

[cae]

Are you also doing it for the stock board? I mean the range check and failsafe?

João

Yes, I have three stock TX's and only one Sky TX, so I will keep working on the stock board.

Colin.

[cae]

Try turning the Tx on with the throttle not idle, but with the module in bind mode. While the Tx is waiting for the throttle to be idle, it doesn't send any pulses to the module.

Mike.

Great idea, so simple, why didn't I think of that.
Thanks Mike.

Colin.

[cae]

Also, you can put the receiver in bind mode, THEN put the TX module in bind mode, and it will bind instantly. So no problem with the 3 secs.

Another great idea I did not think of, how stupid can one person be.

Thanks Kilrah.

Colin.

[cae]

OK, not surprisingly both Mike and Kilrah's suggestions for binding worked. And the opentx PXX on the Sky9x worked as expected

The strange thing is after reflashing the firmware this morning (I had gone back to normal FW to fly yesterday) the module no longer turns off after 3 secs. and can be bound normally. Not sure why, yet.

Colin.

[MikeB]

I've been having a 'play' with a prototype XJT module (meant to be internal to the Taranis). I've managed to wire it up and get it working as an external module to the Taranis, and bound it to both a X8R and a D8R-II. I left it bound to the D8R-II.

I've now updated the PXX code in er9x to match the revised protocol. Using the above module I've got control of a servo on the D8R-II, so the PXX is working. This is currently working on the '128 version of er9x.
One or two things are hard coded at present (like Europe mode and D8 to the D8R-II).
I still need to see about binding and range checking, and adding support for the D16 mode to the X8R.

I've done nothing towards handling the SPORT telemetry protocol (yet!).

I can add all this extra code to the '128 and '2561 versions. I think it is probably worth using up flash space for the '64 version.

Mike.