openrcforums

opentx-r2834
Ok.

OK, this is the wrong firmware, er9x is not openTx, please post again in openTx.

Mike.

On occasions I've noticed slightly odd menu displays when changing menus. You seem to get some of each menu displaying at the same time. Also, the STAT display of tmain is sometimes over 20mS, this is rather long.

I think the problem is caused by things like chainMenu().
What happens is the 'current' menu code is executed, and discovers you have pressed a button causing a different menu to be used.
The menu control is updated to have the new menu as the 'current' one, ant this menu is then called with an indicator saying this menu is being started. When this new menu code completes, the processor returns the the original menu and finishes executing that, so BOTH menus get processed in ONE operation.
I believe openTx works the same way, the code looks to be the same.

I've just done a change so chainMenu() just posts the required menu change, and this is then picked up next time a menu is to be processed. Seems to work fine, and tmain has not gone over 9mS after much jumping around between menus.

I also wondered how often the mixer calculations are performed, so I've added some test code that counts how many times it runs every second. It varies depending on which menu is displayed, but I never saw a number lower than 150, and mostly it is between 190 and 220. This is in PPM mode. Switching to PXX (new version driving 16 channels out), and it drops to around 120 to 150. This is because the PXX output (8 channels sent every 9mS) uses a lot of processor time.
This means the mixer calculations occur at least 3 times for every PPM frame and at least twice every PXX cycle.

Mike.

Just been testing a XJT with PXX supplying 16 channels. I've got two X8Rs bound and responding correctly to the 16 channels.
Just needs a bit more testing!

Current list of changes for the next revision:
Channel order moved to radio setup
Add CH% to timer triggers
Fix timer 2 speed bug
128/2561 add display of all channels
Handle menu switching better
PXX support 16 channels output

Mike.

Very good news!

Just ran the PXX to 2 receivers for an hour, all worked OK. I thought I had seen a situation where the rf link was lost, but it may have been a poor connection between the Tx and the XJT module. I'll run some more tests to make sure all is OK.

I have got one small problem with the CHx% timer triggers. The '128/'2561 versions have extra custom switches, so this means the value for setting the timer trigger to CHx% is going to be different for a M64 and a M128/M2561. There is already a problem as the extra CSwitches move the value for momentary switches along. This is only a problem when moving a model betweem a M64 Tx and a M128/M2561 Tx.

Mike.

Mike: you are working too hard to lure me to do the M128 mod on my back up T9X and spend more money on a XJT and X8R. Don't know whether I should thank you or hate you any more.

There seems to be some sort of problem with the PXX/XJT. Switched on today and the receiver(s) didn't lock on. Switched the Tx off and on, then they did, but a short while later they dropped out. I'll test further, this is not reliable enough yet.

Mike.

I'm beginning to suspect the XJT module. I've just tried it in a 9X ('128), ersky9x, and as an external module on the Taranis.
ALL three showed the same problem, i.e. the receivers lost the link. In all three cases, changing something, to PPM and back to PXX or bind or range check seemed to recover the link.

Mike.

I hope this is just that one XJT problem instead of a protocol issue.

I may have fixed the problem. I think I had a conflict at power on between PPM and PXX that may have confused the XJT. Since I fixed this on the 9X ('128), I haven't got the problem to occur. Possibly it has only started really being a problem since I implemented all 16 channels, with the PXX frame now being sent every 9mS instead of 18mS. I'll be testing the ersky9x version as well. I only saw the problem once on the Taranis, and this may have been something to do with how I was testing.
I thought it was odd as the XJT is the same as built into the Taranis.

Mike.

Just committed r808:

Channel order moved to radio setup - now present even if "no templates" selected
Add CH% to timer triggers - use the ACTUAL channel outputs after safety switches etc.
Fix timer 2 speed bug
128/2561 add display of all channels - LEFT/RIGHT on main screen shows channels 9-16
Handle menu switching better
PXX support 16 channels output
Fix HELI bug
lcd additions for serial lcds (for custom txs)

( I also saved 106 bytes of flash).

Mike.

Mike, thanks.. would you mind to explain this one?

lcd additions for serial lcds (for custom txs)

João

jhsa wrote:Mike, thanks.. would you mind to explain this one?

lcd additions for serial lcds (for custom txs)

João

Yes, very interest!

flybabo has been fitting a 9XR main board to an old Proline Tx. He's using a serial LCD (actually OLED) and wrote an alternative driver to allow for this. He sent me the patches and I added it in as a compile option.
He said:
"There's a group of people building their own transmitters from scratch and they asked the patch files."

So we've put the code into er9x so all the group can compile the version they require.
The Serial LCD is much slower to update than the standard (parallel) one.

Mike.

thanks Mike.. If it wasn't much slower, it could free some pins on the 9x
João

[quote="MikeB"]
Just committed r808:
./quote]

Thanks Mike.

Colin.

MikeB wrote:flybabo has been fitting a 9XR main board to an old Proline Tx. He's using a serial LCD (actually OLED) and wrote an alternative driver to allow for this. He sent me the patches and I added it in as a compile option.
He said:
"There's a group of people building their own transmitters from scratch and they asked the patch files."

So we've put the code into er9x so all the group can compile the version they require.
The Serial LCD is much slower to update than the standard (parallel) one.

Mike.

Thank you Mike for including the patches to the standard release.
I found out minor integration error and I'm attaching a patch tarball correcting the problem.
You may apply this in the next release.

As for the runtime of the serial LCD, even though screen refresh takes 8x longer, it shouldn't affect overall performance of the transmitter since the screen is not refreshed every frame. I think it's a viable option to relieve 8bits of port (PA0-PA7) for other purpose.

Current implementation supports 4 possible LCD combinations: (stock-ST7565-LCD,SSD1306-OLED)controllers x (parallel,serial) interfaces. You may rotate the screen and enable reverse video by setting proper CPP variables in 'lcd.h' and 'lcd.cpp'.

My retrofitting work using a 1.3" parallel OLED is still in progress.

Thanks,
HT

I'm more comcerned with the amount of processor time used to update the display. We have a 10mS time slot for lots of thing. If the serial update takes many milliseconds it could compromise the 10mS timing.

Mike.

Serial LCD takes ~42,000 cycles (2.625ms) to refresh the screen.
If I read code correctly, er9x doesn't use interrupt-driven A/D conversion.
Is there any reason? We may save some cycles by using the interrupt notification.

Yes it reads the A2D values when it needs them. To use interrupts usefully, the A2D would need to run as a background task, then the 'application' software will need to be careful to read the 2-byte result as an indivisible operation to avoid one byte being read, then the value updated by interrupt, then the other byte being read.
I'll give it some thought, and see how much processing time might be gained.
Due to having to "bit bang" the PPM/PXX output, we can't hold interrupts disabled for any length of time.

Mike.

I'm just thinking about DSM and the model number. The current implementation uses the "number of channels" field to hold the "sub protocol" (LP4/5, DSM2, DSM2/X). Since this was done, I've added PXX properly, and we now have a "sub protocol" field in the EEPROM. PXX also uses the "number of channels" field for the model number.

I propose to move the DSM sub protocol to the actual sub protocol location (makes more sense), and then the "number of channels" field will be available for the model number.
This will mean users of DSM will probably need to check their settings after updating, but they will gain a model number that moves with the model.

Mike.

flybabo wrote:

MikeB wrote:flybabo has been fitting a 9XR main board to an old Proline Tx. He's using a serial LCD (actually OLED) and wrote an alternative driver to allow for this. He sent me the patches and I added it in as a compile option.
He said:
"There's a group of people building their own transmitters from scratch and they asked the patch files."

So we've put the code into er9x so all the group can compile the version they require.
The Serial LCD is much slower to update than the standard (parallel) one.

Mike.

Thank you Mike for including the patches to the standard release.
I found out minor integration error and I'm attaching a patch tarball correcting the problem.
You may apply this in the next release.

As for the runtime of the serial LCD, even though screen refresh takes 8x longer, it shouldn't affect overall performance of the transmitter since the screen is not refreshed every frame. I think it's a viable option to relieve 8bits of port (PA0-PA7) for other purpose.

Current implementation supports 4 possible LCD combinations: (stock-ST7565-LCD,SSD1306-OLED)controllers x (parallel,serial) interfaces. You may rotate the screen and enable reverse video by setting proper CPP variables in 'lcd.h' and 'lcd.cpp'.

My retrofitting work using a 1.3" parallel OLED is still in progress.

Thanks,
HT

I have to say that the Screen looks very crisp….. I likey a lot…

MikeB wrote: I propose to move the DSM sub protocol to the actual sub protocol location (makes more sense), and then the "number of channels" field will be available for the model number.
This will mean users of DSM will probably need to check their settings after updating, but they will gain a model number that moves with the model.
Mike.

good. I assume you mean 'Rx number' moves with the model name to new model number.

Yes, the same as the PXX RX number is part of the model, not the slot in the EEPROM it is in.

Mike.

great.

Just find a minor usability thing. the stick scroll is neat. but interestingly for the menu page selection for radio set up, it will get stuck on 5/6 and have to use button/wheel to get it move out of 5/6.
As for pot scroll, there is not enough 'clicks' to go all the way through the radiosetup 1/6 items. Stick scroll seems much better than pot scroll.
the combination of wheel encoder center button function and stick scroll is unbelievable, very easy to use than either by itself.

"Sticking" on page 5/6 is deliberate. It is the analog diagnostic menu, so if stick scroll moved you away from it you wouldn't be able to test the sticks properly.

Mike.

that makes sense. It would be more intuitive once get to 5/6 you need to scroll down to the list to lock it (like other pages to change setting). Then when you are not doing the test by just scroll a little fast and hit the 5/6, you won't get stuck and need get out with a button. i am splitting hairs here.

I might be able to do something like that.

General question regarding slow/delay. I understand that some might like a higher resolution on slow and delay. One suggestion is a 'per model' option to choose a higher resolution. We have values from 0 to 15 available. I'd suggest if the option is enabled, then these become steps of 0.2 seconds for both slow and delay, maximum slow and delay would then be 3.0 seconds. With the option off, you still get the same timings as you currently have.

Mike.