Custom light controller for Spektrum receiver/ESC

[oops]

At the moment I'm monitoring PWM on the Aux channel, so the switch can activate the lights, and access the menu, but obviously you don't get brake lights. I've also tweaked how the menu works so that you can set brightness levels using the button rather than the AVC adjuster.

For a non-smart receiver, you really need to monitor the throttle and the aux channel, but my prototype only has a single input.

The PCBs I've got coming have two inputs, plus a physical switch on the controller which could be used to access the menu if you don't have an aux channel.

On the software side, the code measures the pulse width to work out whether it's looking at PWM or a Smart signal, and then switches mode.

 

[LipoShirly]

At the moment I'm monitoring PWM on the Aux channel, so the switch can activate the lights

Ok, that makes sense. Nice work by the way.

 

[oops]

A small batch of PCBs finally arrived yesterday. Lack of stock at the manufacturer meant that they couldn't fit the processor, and a silly mistake by me on the order meant that the USB port, switches and crystal didn't get fitted either:

Lots of staring into a microscope and I managed to fit the rest of the components for one board last night. I've now had a chance to try it in my Felony, and it works perfectly!

As I mentioned, this board has dual inputs, so that it can do a better job of supporting standard (non-Smart) RC gear, so I can now do a bit more work on the software for that. It's also got a hardware button that can be used for configuring it if you don't have an aux channel. The second button is used to flash new firmware.

I'd be interested to hear any suggestions for features to add to the controller.

 

[LipoShirly]

First of all I'm impressed you were able solder the processor, the pitch on those devices is beyond my skill set. You've inspired me into possibly adding the PWM "input' into a current project, can I ask how your measuring duty cycle? Are you simply measuring time between edges? or using the timer/counters of the processor?
Suggestions, certainly the brake light addition you've mentioned, but if your monitoring control PWM signals , then add another channel and watch the servo , you could then flash the appropriate light ( turn signal ).

 

[oops]

The processor is soldered using hot air - an excuse for some new tools There's a lot of videos on the internet that make it look a lot easier than it is!

For the PWM, I'm using the RP2040's Programmable IO (PIO) feature, which effectively allows you to write a separate program that runs independently of the main CPU using a very limited 9 instruction assembly language to take care of I/O tasks. This counts the number of clock cycles between rising and falling edges.

I did try measuring it using interrupts in the main code, which worked, but was much less accurate. Certainly good enough for detecting if a switch channel is on or off, but not ideal for analog controls.

I think the processor can also read PWM signals using the built-in PWM hardware, but it's not supported in MicroPython which is what I'm using. Have you already got a microcontroller?

I've been thinking about doing turn signals from steering. Don't think it'd really suit the Felony but I know people like it on scale RC.

 

[LipoShirly]

For the PWM, I'm using the RP2040's Programmable IO (PIO) feature, which effectively allows you to write a separate program that runs independently of the main CPU using a very limited 9 instruction assembly language to take care of I/O tasks. This counts the number of clock cycles between rising and falling edges.

Ahhh, I'd forgotten about the pi being able to do the parallel process stuff, didn't realize the smaller variants could do something similar. (wait, did you say assembly? nice...)

I picked up a Trinket M0 from adafruit, it uses the ATSAMD21E18 (its essentially a little eval board) . I simply wanted my headlights to "breathe" but that was kinda boring if it did it all the time so I added one of the adafruit accelerometers to determine if car was in motion or not. no motion = breathing, motion = fast flash. I had already purchased a $5 device from Amazon that plugged into the AUX channel as an ON/OFF circuit, the same as you built and coded. Once it was built I had a spider web of wires and 3 small circuit boards ( Trinket, accel and output FETS ) to mount and I just couldn't come up with a quick graceful way to do it, until I saw your thread and decided to put it all on a mother board of sorts. The Trinket and accel boards will mount on headers, the FETs can now be SMD and all the wires go away. If I add the ability to watch the AUX channel I can dump the amazon device.....
Anyway , thanks again for the info.

 

[oops]

Ahhh, I'd forgotten about the pi being able to do the parallel process stuff, didn't realize the smaller variants could do something similar. (wait, did you say assembly? nice...)

Actually I think the PIO feature is only on the RP2040/Pico, although the Pi 3 & 4 have 4 full cores. If you're interested the PIO code for reading the PWM pulse is here.

Looking at the summary for the ATSAMD21E18 it says that it's got several Timer/Counters that can be used for Input Capture, so I'd imagine that you can set those up to measure the pulse width to achieve the same result. For RC, it's the pulse width rather than the duty cycle that matters, although I think for any given receiver it amounts to the same thing.

The breathing lights sounds interesting - I'd be interested in seeing a video. Before I discovered the Smart protocol, I was playing with using an accelerometer to detect movement. How well does that work? Are you just looking for vibrations?

 

[LipoShirly]

The breathing lights sounds interesting - I'd be interested in seeing a video. Before I discovered the Smart protocol, I was playing with using an accelerometer to detect movement. How well does that work? Are you just looking for vibrations?

Plenty of references on-line, although this is among the best I've found describing a Breathing LED . I believe there are kits out there that already do this for RC, I just wanted a little more control over the rates and such. A video of my lights is below, the two LEDS will be right and left headlights on the Typhon. How well does the accelerometer work ? short answer , good enough. Long answer..... its probably not the perfect fit for all applications, but will work fine for a basher. The problem would be if I was on a smooth surface, in a straight line at a constant speed (i.e. acceleration = 0) then the LED mode would flip back to breathe. Am I looking for vibrations ? , essentially yes, I sum all 3 axis for movement, anything above a certain threshold triggers the LED mode.

Thanks for taking a look at the data sheet, I did notice using TCs for output related functions, but not input. I'll have to reread.

 

[oops]

I now understand what you're doing - that's very cool. I may borrow that idea

I never got as far as testing the accelerometer in a car, but my guess was that even on a smooth road there would be enough vibration and constant accelerations to trigger movement detection.

It turns out the PCB wasn't quite perfect. The input MOSFETs aren't quite fast enough to handle the Smart serial signal. Interestingly, they work absolutely fine on the control packets from the receiver, but always drop exactly the first 5 bytes of the telemetry packets. Bodged a fix to confirm that was the problem, now waiting for some replacement SMD ones.

 

[LipoShirly]

It turns out the PCB wasn't quite perfect. The input MOSFETs aren't quite fast enough to handle the Smart serial signal.

Those BS170s are pretty standard switching FETs and should work fine for this app. I think your problem is the pull up value , your earlier schematic shows 10K, is that what you put in there ? Looking at the RP2040 data sheet at VREG_VOUT I see that the pin is good for 100mA. I'm confused that you have it labeled 3.3V, it looks as though its only adjustable up to 1.3V. Anyway, that 100K is much too large in that configuration, the turn-OFF speed ( pin returning to 3.3V ) will be really slow. As mentioned with 100mA available you can change that to 100Ohms and only pull 33mA from that VREG_OUT pin, but your speeds will significantly faster.
I SPICED it just for fun...... the 2 circuits are identical except for the pull up resistor. The time base is in the uSec range, I'm guessing the serial signal is not that fast, but you get the idea.

 

[oops]

Wow - thanks very much for that analysis! I've never used Spice, although it looks like I should. You're right - the BS170s are fine. Unfortunately, the PCBs ended up with AO3400As which can switch loads of current which is nice for the LED drivers, but I also used them for the inputs, which was a mistake.

Out of interest, is it able to simulate the A03400A? The PCBs actually ended up with 1k resistors rather than 10k.

The Smart serial is 115200bps, so bit width is around 8.7us. The protocol allows negotiation up to 400kbps.

The prototype is successfully using 10k with a BS170, but your graph suggests that that must be a bit borderline.

Regarding the 3.3v supply, the schematic is for the Pico microcontroller board, so that's the 3.3V from the board's regulator rather than the RP2040's VREG_OUT which is 1.1V. My PCBs have an NCP1117 3.3V regulator which is rated to 1.1A.

 

[LipoShirly]

Unfortunately the AO3400 is not in my library of SPICE parts. Looking at the AO3400 data sheet it should be every bit as fast as the BS170, its claim to fame is it's incredibly low Rds(on) resistance ( Those are some impressive max current spec's). At 1K your probably still a little slow to recover, I would definitely go with a lower resistance. It sounds like you've got plenty of power supply current, I'd just keep an I eye on your power dissipation through the resistor and drop down to 50 Ohms or so. With 3.3V and 50 Ohm I get 60ish mA and just under 1/4W.... Last time I did level shift or input buffer I used this little fella, SN74LV1t34
SPICE, if your looking to try it out I'd recommend the Linear Technology ( now Analog Devices ) free version called LTSPICE .

I'll be waiting for the video of that Felony with some breathing LEDs, that would look sweet...

 

[oops]

Thanks - I'm struggling to get my head around which feature of the transistor causes the slow rise in that graph. I'm guessing it's the output capacitance, in which case the AO3400 is somewhat worse that the BS170 (75pF vs 17pF). The input capacitance of the AO3400 is much worse, but I'm not sure if that's relevant here.

I did try to find an IC that would do the level shift, but I couldn't find anything suitable that would work with more than 5V input, as the BEC is running at 7.4V.

I'll be waiting for the video of that Felony with some breathing LEDs, that would look sweet...

It's coming

 

[LipoShirly]

Thanks - I'm struggling to get my head around which feature of the transistor causes the slow rise in that graph. I'm guessing it's the output capacitance, in which case the AO3400 is somewhat worse that the BS170 (75pF vs 17pF). The input capacitance of the AO3400 is much worse, but I'm not sure if that's relevant here.

Your on the right track, the FETs input capacitance would certainly slow down the switching speed, but is it relevant in this application? depends on the circuit driving it ( in this case the receiver). The "stiffer" the output is (low impedance) from the receiver , the less switching time difference you will see between the 2 FETs. My guess is the receiver is probably built such that the switching time difference would be negligible, but definitely slower with the AO3400. And yes on the output capacitance also slowing down the switching time. The larger the pull up resistor then the more important that output capacitance becomes, and vice versa, make that pull up smaller and the switching times begin to look the same. Short answer, I'm with you... change out those AO3400s.......but lower that pull up.

I was thinking you were working with a 6V BEC, so yeah the SN74 device wont work..... take a look at the CD4010. Kinda overkill for a single channel, someone's gotta make a single channel version...

 

[oops]

I've had a quick play with LTSpice, and managed to find models online for both BS170 and AO3400, and the AO3400 is much worse, which does at least seem consistent with reality. I can only get a graph for the BS170 that's consistent with your green line if I use 100K rather than 10K.

Board #4 is done, and I finally got one done that I'm happy with:

The "stiffer" the output is (low impedance) from the receiver , the less switching time difference you will see between the 2 FETs. My guess is the receiver is probably built such that the switching time difference would be negligible, but definitely slower with the AO3400.

Interestingly, I only see problems with messages from the ESC, not from the receiver, so I think the output impedance of the output device may be a factor here.

I was thinking you were working with a 6V BEC, so yeah the SN74 device wont work..... take a look at the CD4010. Kinda overkill for a single channel, someone's gotta make a single channel version...

Yeah - it seems silly that most awkward part of this circuit is dropping the voltage on that input!

Thanks again for the input on this. I'll definitely drop that pull-up if I get more made.

 

[oops]

New transistors (2N7002K) arrived and do appear to fix the problem. I did some testing using another Pico as input, and the 2N7002s work reliably up to the Pico's max of 7.8 Mbps (100ns pulse width). Interestingly, the A3400s seem to work reliably up to a bit over 1Mbps on the test bed, despite seeing problems at just 115.2kbps with the ESC signal, so I think the issue may be down to a relatively high output impedance on the ESC, and the relatively huge input capacitance on the A3400.

I've also taken a first stab at a case for the board. The lid has a couple of print-in-place plungers that press the buttons on the PCB.

 

[oops]

Having sorted out the hardware issues, I've now made a load of progress on the software, and made it ludicrously configurable. New features include:

• Full support for normal, non-Spektrum Smart RC kit
• Three different brake modes for normal RC kit
• Automatic turn signals on steering, with configurable threshold for turning them on
• Breathe animation when "sleeping", with configurable brightness, speed and gap between "breaths", and delay before it kicks in.

I need to get a video of the Felony, as it does look awesome with the breathe mode - thanks to LipoShirly for the suggestion.

I'm now looking at getting a small production run done, but need to get a bit more real world testing in first. Most of my testing so far has been done with this high-tech RC simulator

 

[Starfox2005]

Having sorted out the hardware issues, I've now made a load of progress on the software, and made it ludicrously configurable. New features include:

• Full support for normal, non-Spektrum Smart RC kit
• Three different brake modes for normal RC kit
• Automatic turn signals on steering, with configurable threshold for turning them on
• Breathe animation when "sleeping", with configurable brightness, speed and gap between "breaths", and delay before it kicks in.

I need to get a video of the Felony, as it does look awesome with the breathe mode - thanks to LipoShirly for the suggestion.

I'm now looking at getting a small production run done, but need to get a bit more real world testing in first. Most of my testing so far has been done with this high-tech RC simulator

View attachment 199929

Wow that's amazing!

 

[oops]

In testing the boards I've got here, I discovered an issue that I'd overlooked: connecting the gate of the input mosfets directly to an exposed pin leaves them very vulnerable to electrostatic discharge damage, and I've been killing mosfets when handling them. The 2N7002Ks seem particularly sensitive despite the datasheet claiming they have some ESD protection built in.

I've now modified some of the existing boards to add some proper ESD protection, and I've not yet managed to cause any further damage on one of these boards.

I've also got a revised PCB design which adds a third input, two more outputs, an option for external LED power, and manages to be slightly smaller than the previous design.

And a new design of case for the existing boards, that puts the connectors on the end rather than the top.

 

[Tex Koder]

In testing the boards I've got here, I discovered an issue that I'd overlooked: connecting the gate of the input mosfets directly to an exposed pin leaves them very vulnerable to electrostatic discharge damage, and I've been killing mosfets when handling them. The 2N7002Ks seem particularly sensitive despite the datasheet claiming they have some ESD protection built in.

I've now modified some of the existing boards to add some proper ESD protection, and I've not yet managed to cause any further damage on one of these boards.

I've also got a revised PCB design which adds a third input, two more outputs, an option for external LED power, and manages to be slightly smaller than the previous design.

And a new design of case for the existing boards, that puts the connectors on the end rather than the top.

View attachment 202670

Good catch and fast resolution!
Your design looks very well thought out, I love it!!

Any estimates of final cost.. MSRP?

.