Hello All,
Please be so kind as to cast your eye over the attached. It's a PCB layout for Phil'd 7 Chan encoder with a few extras. Designed for a NANO, as I can get them easily, I've added a few things tomake them fairly universal:
1. A circuit for charging the batt with barrel connector.
2. Choice of on-board or external Rate and Expo pots.
3. Third pot for 'something'.
4. Three configurable jumpers (servo reversing or 'something') or an LED can be added (low battery?)
5. A seperate header for the TX module.
6. An analogue/voltage input for battery voltage detction (low batt alarm).
7. Internal/external buzzer.
8. Calibration jumper (paralleled with the S/C button), if you haven't fitted the button.
I've tried to add everything that I could think of to make a custom conversion easier. You simply don't solder in the bits you don't want. I'll order PCB's a bit later and should have them in the week and then give it a whirl. I will make a few small changes to the code to suit my own TX (two channel, Futaba FP-2GS).
I'll post all the files here when I am sure the bugs are out.
Buonissimo!
PCB for Phil's 7 Chan Encoder
-
- Posts: 39
- Joined: 19 Feb 2018, 19:19
PCB for Phil's 7 Chan Encoder
- Attachments
-
- Phils7Chan.jpg (53.55 KiB) Viewed 2956 times
-
- Phils7ChanR1.pdf
- (20.04 KiB) Downloaded 169 times
Last edited by belli on 29 Jun 2018, 07:21, edited 2 times in total.
-
- Posts: 60
- Joined: 18 Feb 2018, 20:14
Re: PCB for Phil's 7 Chan Encoder
Hi Belli
I could not see anything obvious that is wrong with the circuit on this my first look (on a smug phone which does not help).
I take it the data lines use the internal pull-ups in the Nano.
According to the adage ' nothing is foolproof to a sufficiently talented fool' you might wish to consider solder links or jumpers on your analog channels that give
options in order to force a choice. Someone could fit an on board control then mistakenly plug in to the external header ( if fitted) and end up with one at min, one at max thus shorting the supply rail. Doing the same to the Aux2/ battery divider network would also help avoid getting false readings.
Other than those possibly personal views, it looks a well thought out design.
All the best for your design.
Ade
I could not see anything obvious that is wrong with the circuit on this my first look (on a smug phone which does not help).
I take it the data lines use the internal pull-ups in the Nano.
According to the adage ' nothing is foolproof to a sufficiently talented fool' you might wish to consider solder links or jumpers on your analog channels that give
options in order to force a choice. Someone could fit an on board control then mistakenly plug in to the external header ( if fitted) and end up with one at min, one at max thus shorting the supply rail. Doing the same to the Aux2/ battery divider network would also help avoid getting false readings.
Other than those possibly personal views, it looks a well thought out design.
All the best for your design.
Ade
-
- Posts: 39
- Joined: 19 Feb 2018, 19:19
Re: PCB for Phil's 7 Chan Encoder
The PCB has arrived, good thing I didn't spot all my mistakes before ordering it...
I've updated the files and will post them when I have everything working. The biggest error is that the central pin is the signal and the outer pin +ve, this means when using servo leads to hook things up that red becomes signal and orange (or white) is +ve. Not a major problem really. The switch connection should have Common and Batt swapped.
I'll flash the Arduino later...
I've updated the files and will post them when I have everything working. The biggest error is that the central pin is the signal and the outer pin +ve, this means when using servo leads to hook things up that red becomes signal and orange (or white) is +ve. Not a major problem really. The switch connection should have Common and Batt swapped.
I'll flash the Arduino later...
-
- Posts: 39
- Joined: 19 Feb 2018, 19:19
Re: PCB for Phil's 7 Chan Encoder
So...
I flashed the Nano, there are a number of places where the sync pulse needs to be edited to get it working.
I have a funny here,the width of the pulse is not from the rise to the fall but from a rise to the corresponding rise. Maybe the Flysky TX modules need the signal like that but it seems odd to me. I would think that the width of each pulse should be the corresponding pulse width. I've attached a sketch to show this, I could grab the wave form off the scope but it's a bit tedious.
My rates/expo are screwed all the way down and I have calibrated the sticks.
Am I just dum?
I flashed the Nano, there are a number of places where the sync pulse needs to be edited to get it working.
I have a funny here,the width of the pulse is not from the rise to the fall but from a rise to the corresponding rise. Maybe the Flysky TX modules need the signal like that but it seems odd to me. I would think that the width of each pulse should be the corresponding pulse width. I've attached a sketch to show this, I could grab the wave form off the scope but it's a bit tedious.
My rates/expo are screwed all the way down and I have calibrated the sticks.
Am I just dum?
-
- Posts: 744
- Joined: 16 Feb 2018, 14:11
- Location: Warwickshire
Re: PCB for Phil's 7 Chan Encoder
I think that's right - the value for a channel is measured between two rising edges (or two falling edges which is usually the same), The pulse width is usually fixed (commonly at 300 microseconds) and conveys no information. Some manufacturers used to vary the width of the pulses too on some of their systems - to transmit additional information - fail safe positions and such.
-
- Posts: 39
- Joined: 19 Feb 2018, 19:19
Re: PCB for Phil's 7 Chan Encoder
On the 'analogue', 35MHz and such equipment, isn't the pulse width sent exactly as such to the servo? Isn't the servo expecting a pulse width, rising edge to falling edge of 1-2ms?
-
- Posts: 744
- Joined: 16 Feb 2018, 14:11
- Location: Warwickshire
Re: PCB for Phil's 7 Chan Encoder
You're confusing two separate things:
Actually, more modern receivers don't do that - but that's how the older ones operated, and the concept is still correct.
- the pulses sent to each individual servo, which are indeed pulses nominally 1ms to 2ms wide sent about fifty times per second (so every 20ms).
- the combined pulse position signal, used in buddy box leads, and the signal sent to the RF section. This consists of a train of pulses - a first marker pulse, and then one pulse for each channel. The pulses are all (normally) 300 microseconds wide, and it is the time delay between each pulse and the next that represents the channel value - again 1ms to 2ms. The whole frame repeats fifty times per second, so eight channels (nine pulses) can be packed into the 20ms frame while still allowing a longer than 2ms gap between the last pulse and the first pulse of the next frame - this longer gap serves as an 'end of frame' marker. With all 8 channels at their maximum value of 2ms the whole frame of 9 pulses lasts 16.3ms (the point three is due to the 300 microsecond width of the last pulse). This, by the way, is why 8 channels was a common maximum number. If you wanted more channels than that you either need to use different timing than 1 to 2 ms or accept that the whole frame couldn't be transmitted fifty times per second. The first option means that you can't easily use standard servos, and the second one gives a slower less responsive link between transmitter and receiver.
Actually, more modern receivers don't do that - but that's how the older ones operated, and the concept is still correct.
-
- Posts: 39
- Joined: 19 Feb 2018, 19:19
Re: PCB for Phil's 7 Chan Encoder
Thanks Martin, I'm learning...
I found some nice docs here:
http://www.omegaco.demon.co.uk/mectnpdf/mectn003.pdf
http://www.omegaco.demon.co.uk/mectnpdf/mectn004.pdf
Haven't read them yet but all the good stuff seems to be in there.
I found some nice docs here:
http://www.omegaco.demon.co.uk/mectnpdf/mectn003.pdf
http://www.omegaco.demon.co.uk/mectnpdf/mectn004.pdf
Haven't read them yet but all the good stuff seems to be in there.