openrcforums

Some users have reported several requests:
- there was a bug in the program about the jumper used for selection between channels 1-8 and 9-16 (when SBUS is used).
- there was not alway a need to automatically detect if the signal is CPPM or SBUS (so no need to connect the signal to pin 8 when only SBUS is decoded).
- there was a need to use other arduino pins to control the servos.

Please find in attachment a new code that gives a solution to those requests.
The user can now easily change up to 4 parameters depending on his preferences without having programming skil.
Intructions are at the top of the file.

Edit : There was a bug in the version posted initially. When pins were modified, there was some big jitter on some servos.
I deleted the wrong version and replaced it with a new one that fix this issue.

http://forum.autoquad.org/viewtopic.php?f=33&t=4256

Just in case anyone want to get the s.bus without using an inverter this post shows how with a x4r.

I was thinking I might just do this with a bit of vero board, and make as many channels as I need for each plane and solder the servo wires to the veto board at the exact length etc, making a neat but permanent installation but still having the RX easily swapped out with just one plug!
Only down side would be soldering needed if servo break.

Boards and parts arrived! I have populated one board. Either 0805 components are getting smaller, or my eyes are getting older! Here's some pics:

Very nice, much neater then my intended vero board .
Have you tested yet?

Expanding on the idea more one could do away with the arduino and put the atmega 328 on the board itself.

Success!

Hi I just hooked up a test with the x4r and taking the none inverted output via a 5k6 resistor to be safe to this project and it worked fine so no need there for the inverting transistor on the x4r at least.
I connected 2 servo , one from the arduino and another from the x4r pwm, same channel and put servo side by side to see if there was any difference in performance.
I think the servo from the arduino was maybe very slightly slower if sticks were wiggled like mad but it was only very slight and may even have just been my imagination, i think in reality the performance will be same.

I tested on 2 boards with the 328 processor and the cheaper one with the big silver xtal worked but only on 5v bec, where as the newer version with bigger chip worked on a 1 cell lipo which was half chargerd. something to bear in mind.

OK I built a very board version and a inverter for the x6r,
The inverter worked with out supplying the collector with 5v via resistor so made it easier.
I used pins on one side of arduino only for a neat job, I will post a PIC later.

All worked apart from pin2, the servo on that channel chatters apart from when it is centred.
Is anyone else getting this?

Also I would like to have the use of pin8 for an output and not bothered about ppm input.

Any help appreciated.

nigelsheffield wrote: All worked apart from pin2, the servo on that channel chatters apart from when it is centred.

dId you deactivate the debug option? When debug is activated, Arduino can't handle interrupts on a regluar basis and this could generate some chatters.

Otherwise I do not understand. Did you try changing (in the setup) the sequence of the pins being used by each channel? In this case does it happens on a different channel?

nigelsheffield wrote: Also I would like to have the use of pin8 for an output and not bothered about ppm input.

I think that you can try to use pin 8 if you disable CPPM decoding (this must be tested with the latest version, the version that allows to change the setup).
I did not test this but I presume it should work. if not, let me know and I will check the code.

I did not do anything with debug, I used the one posted here a few posts back, should I do something with debug then?
I tried assigning different channels but it was always pin2 that caused the chatter.
I have it with only s.bus only by default.
Late now but will try again tommorow.
Will also try to disable debug if I can figure out how, and try a different arduino on pin2 to make sure its not just the arduino but seems unlikely as it works but jitters at anything other then centre, the jitter get worse the further the travel is from centre.
I also tried a different RX , the x4r without the inverter cable to make sure it was not that but its the same.
I test it with no ftdi cable connected by the way.
Thanks for helping, I'll update tomorrow when I try out other board.

The version posted here a few posts back has the debug option deactivated (because this line "//#define DEBUG" begin with "//" and so is considered as comment).
So, normally you should keep this line unchanged.

In this version, you can define the pins used to generated the PWM signals to control the servos. This is done by this line:
#define PINS_FOR_OUTPUTS_1_8 A1 , A2 , 5 , 6 , A3 , 4 , 3 , 2

I see here that pin 2 is the last pin in the list. Perhaps there is a bug in the arduino code that generates jitter on the last pin.
In order to test if the issue occurs always on the last pin defined in the list, I suggest that you invert the sequence of the pin in the list.
E.g. you could invert pin 2 and 3, so modifing the line in :
#define PINS_FOR_OUTPUTS_1_8 A1 , A2 , 5 , 6 , A3 , 4 , 2, 3

If the jitter continues on pin 2, I presume that there should be an issue with the connections between pin 2 and the servo or with the servo it self.
if the jitter occurs now on pin 3, the issue still could be
- in the arduino code (and I would have to check it)
- on the Tx side. Even if it is unlikely, it could be that the Tx send on the last channel (so channel 8 or 16 depending on you set up) a value that is not stable. It could be casused by a bad potentiometer. In order to be sure that the value for this channel is stable, I would suggest that you just use a mixer with 100% of another (stable) channel (e.g. channel 1)

OK here's what found ,
If pin2 is the last pin is ch8 then it works fine, and this sequence works so all good
98765432

But if pin2 is elsewhere in the sequence it jitters.

So not really a problem but need documenting perhaps?

And I used pin8 with the s.bus defined and that works fine.
Thanks.
Nigel.

Here is my simple small solution for the veto board.
I just soldered the header on hero board for plus and minus,
And soldered bent header pins on arduino.
For power to arduino I soldered a jst connector on a wire for plugin into veto board.

As long as it does not unplug itself it seems a neat easy solution.

I really do not understand why pin2 should generate jitters if used elsewhere than the last pin.
There is nothing special in the code for pin2 and this pin has no alternative function (at least as output) in the MCU.

So I suspect that there is another issue but I do not know which one.
Are sure that it is not the servo?

Do you have a logic analyser?. This would allow to log the PWM pulses and to measure them accurately.

Sorry , no logic analyser,
Defo not the servo , I tried several, and all the same result.
It is strange , I tried pin2 on channel 7 and channel 1 and different servos and it chatters if not centered, but on ch8 it works fine.
Like I said, it does not bother me as I am happy it works.
But I know what its like when something is not right, its nice to find out why.
I tried 2 arduino pro mini 328 and both the same.
You could Try it yourself and see if it does the same, I am willing to bet it will!
Nigel.

You are using the array:
savedPulses[] in the interrupt routine, and setting this array in:
convertBufferToChannelMicrosec()

Each entry is 16 bits (2 bytes). Any writes to this array should be protected from being interrupted as the interrupt could occur between writing the first byte and writing the second.

Mike.

Mike,
Thanks for your message.
It could be that it allows me to find the issue even if the solution is not exactly the one you suggest.

I think that I do not do not have to avoid interruption when I write new values to the savedPulses array because I intended already to avoid to read the array in the ISR routine while the array would be written.
This is supposed to be done by the test on the variable "pulseReady" in the ISR. Array should be read only if "pulseReady" == true. In convertBufferToChannelMicrosec, I put "pulseReady" = false while updating the array. The drawback is that the update of the PWM pulses width could be delayed (but just by about 3 msec) but the advantage is that the interrupts are never delayed and so there should be no jitter at all.

Still I think that I made a stupid mistake using "&" instead of "&&" in the test and so it does not work as expected.
In ISR there is :
if ( (pulseReady) & ((servoIndex & 0x01) == 0 ) ){

and it should be:
if ( (pulseReady) && ((servoIndex & 0x01) == 0 ) ){

Mike, could you confirm that I am rigth saying that interrupts does not have to be avoided while writing the array (in convertBufferToChannelMicrosec) if the test on "pulseReady" is corrected?

Nigel, perhaps can you make a new test with the proposed correction (replacing first "&" by "&&" in the line "if ( (pulseReady) & ((servoIndex & 0x01) == 0 ) ){"
Thanks for your feedback.

You are right, the pulseReady flag should avoid the interrupt update problem, I missed that.

Mike.

Additional note:
Even if (from a logical view) first "&" should be replaced by "&&", I am still not sure that this would solve the issue because I expect that both (& and &&) give the same result in this special instruction (the 2 terms of the operator being boolean).

Nigel,
Could you send me the set up that you used for your tests.
So I can use exactly the same.
I presume that you used something like:

#define CPPM_SBUS SBUS
#define PINS_FOR_OUTPUTS_1_8 2, 3, 4, 5, 6, 7, 8 , 9 // or similar
#define CHANNELS_TO_DECODE CHANNELS_1_8
//#define PIN_FOR_JUMPER 1 // in fact this line should not have an impact if previous line ask for discarding the jumper.

Nigel,
You said that you build the inverter without a resistor on the collector.
It means that when the transistor is off, the voltage on arduino rx pin goes high via the inernal pullup resistor.
The value of this resistor is perhaps to high in order to let the voltage goes up very fast. Than it could be that the SBUS is not read correctly.
Perhaps can you make a test adding a resistor (1k-2k between collector and arduino vcc) to be sure that this is not the reason of the issue.
Still very strange that jitter happens only with pin2.

Just in case someone wants to have a look, here is a similar project that converts S-BUS to 16 channels, with configurable failsafe on all channels, set with a push button, in case the S-BUS connection is lost.
The relevant part is at the end of the first post..

viewtopic.php?f=91&t=5476

João

Nigel,
No need anymore that you make new tests for the time being.
I can reproduce the error. It is not only for pin2.
It has probably been introduced when I allowed to change easily the setup.
I will fix it.

I found the mistake and fixed it.
I edited the post from feb 09. I deleted the wrong attachement and replaced it by the new version.

Nigel, can you confirm that it is OK?

Perfect now thanks!
I can have the order how I originally intended now!
Any chance you could incorporate the failsafe feature that mikes version has sometime?
I like both version for different reasons, yours has easy swap over from ch 1 to 8 , 9 to 16, mikes has failsafe.......not that I ever WANT to test it in the real world lol!
Hard to tell for sure but I think yours is giving a better servo responce.
Anyway great work!

Hi. This is a great project and I would really like to use it for my FPV platform. I have a few arduino pro micro (Leonardo) lying around.
I'm having trouble loading the sketch on there. Is there any chance this code will run on a pro micro?
Many thanks!

Ramonster wrote:Hi. This is a great project and I would really like to use it for my FPV platform. I have a few arduino pro micro (Leonardo) lying around.
I'm having trouble loading the sketch on there. Is there any chance this code will run on a pro micro?
Many thanks!

I have no experience with a pro micro. It uses a different processor (with integrated USB).
Still I expect that the program should run on it.
Otherwise you could buy an arduino pro mini (it costs only about 2$ on ebay).

Which kind of trouble do you have loading the sketch?

Please note that the sketch is written for a 16 mhz processor (running normally at 5 volt).

mstrens wrote:

Ramonster wrote:Hi. This is a great project and I would really like to use it for my FPV platform. I have a few arduino pro micro (Leonardo) lying around.
I'm having trouble loading the sketch on there. Is there any chance this code will run on a pro micro?
Many thanks!

I have no experience with a pro micro. It uses a different processor (with integrated USB).
Still I expect that the program should run on it.
Otherwise you could buy an arduino pro mini (it costs only about 2$ on ebay).

Which kind of trouble do you have loading the sketch?

Please note that the sketch is written for a 16 mhz processor (running normally at 5 volt).

Thank you so much for your reply. I will put in an order for a few pro mini's.

When I set the board to "Leonardo" and hit "Verify" these are the errors I'm getting:

CPPM_SBUS.ino: In function 'void init()':
CPPM_SBUS:367: error: 'UCSR0B' was not declared in this scope
CPPM_SBUS.ino: In function 'void USART_Init(unsigned int)':
CPPM_SBUS:408: error: 'UBRR0H' was not declared in this scope
CPPM_SBUS:409: error: 'UBRR0L' was not declared in this scope
CPPM_SBUS:411: error: 'UCSR0B' was not declared in this scope
CPPM_SBUS:413: error: 'UCSR0C' was not declared in this scope
CPPM_SBUS.ino: In function 'void loop()':
CPPM_SBUS:824: error: 'UCSR0A' was not declared in this scope
CPPM_SBUS:824: error: 'RXC0' was not declared in this scope
CPPM_SBUS:826: error: 'UDR0' was not declared in this scope
'UCSR0B' was not declared in this scope


Thanks again for your help!

Looking at the datasheet of the processor for the arduino pro micro, I see that the internal registers for the serial communication (USART used to get the SBUS data) have different names compared to the arduino pro mini.
If you want, I can try to write a version with the named as expected by the arduino promini.
I expect I just have to make a few renames in the code.
I could check if it compiles correctly but I can't test if the code is completely OK because I no such a board.

Let me know if you want that I make thoses changes or if you will anyway go for buying arduino pro mini.

Wow. That is incredibly friendly!
I would appreciate that very much!

Here a version that can be compiled on an arduino pro micro (I just made some renames)
Be careful because I have not tested if it really works.