Project Logs

Collapse logs

• Power Schematic, Wiring & XT90 Anti-Sprak

  dudeskidaddy • 10/09/2016 at 22:46 • 0 comments

  Wiring Schematic for the battery box 2x5s series = 10s

  The idea is to be able independently balance charge 2 batteries that are connected in series to the VESC without having to open up the box. You can't just put a charger on the series output and performa balance charge. The batteries need to be isolated. Ideally, all the ports to both ARM and balance charge are accessible from the outside and done in such a way that prevents accidentally hooking up the wrong thing and causing a fire...or worse. All the wiring has to fit in the space and the ports will be mounted and glued through the box.

  There will be 2 XT90 "Anti-Spark" Jumpers that both need to be plugged in to "arm" the board. When the jumpers are out the batteries are completely disconnected from each other and the positive terminal to the VESC. Both batteries could then be charged at the same time or independently via the XT60 ports. Again, all these XT ports and both battery's 5s balance ports will be permanently mounted through the battery box and we won't need to open the box or unplug any wires.

  Why use both XT60 and XT90?

  The jumper ports (XT90) are intentionally different types than the charger and output ports (XT60). This is to prevent accidentally shorting PWR/GND with the arming jumpers which would be bad.

  Terminal ports...on the back side of the battery box. This side faces backward on the board. The jumpers would be dangerous if you put one on a charge or output port. But since the jumpers are XT90, they can only be used to connect to the XT90 jumper port and won't fit the others.

  Here is the whole mess all soldered and hooked up to the LIPOs.

  Both 10s batteries ( storage-charged at 50%) showing 37.81V. Note the 2 XT90 Jumpers in place. All this stuff has to fit in the small area in front of the batteries. I could have used shorted wires, but based on past experience I personally think it's easier to fit longer ones. Usually it's getting them to bend the way you need them to is the hardest part...not fitting all that wire..and longer wires are easier to bend. We'll see. I haven't mounted to the box yet and crammed it all in. I think it will fit.

  A problem with the XT90 anti-spark jumper:

  Before connecting the batteries, I tested each port using the multimeter (Ohms) . I just wanted to make sure I soldered it according to the schematic and in particular didn't do something stupid that would short the batteries. This much energy in one place kind of freaks me out a little bit. Anyway, turns out the XT90 Anti-spark jumpers don't connect unless they are inserted ALL THE WAY! This is a problem since the box is about 2.5mm thick and will hold off the plug by that much. The jumpers are not conducting in this configuration...they have to be completely seated to work.

  Thats the port on the left that will be mounted through the box and glued. The jumper is on the right. Like before, the mounting method takes advantage of the XT90's raised edge to provide extra resistance to pulling forces...glue isn't enough. Since these jumpers are going on and off every time the board is used...they have to be rock solid.

  I must have had just enough coffee this AM. I think if I can cut off this much of the jumper's shield, the plugs inside will make contact even when held out more than 2mm.

  XT90 anti-spark....not sure if they're the best choice.

  So apparently there is only about 2mm of contact distance on an XT90 Anti-spark plug...pretty bad. In these anti-spark units, there are 2 contact points, the first one near the outside has a little resistance to prevent the spark, and the second part of the contact near the back is fully connected. There is an insulator between. I bet the regular XT90s have more than 2x the contact area. Definitely the weak link in the power supply. Wonder if anyones written about this?
  

  Hooked up and the wires fit...just barely.

  Next step is sand, and epoxy everything in place, put labels on the various ports. I made the balance lead horizontal and moved to the bottom...

  Read more »

• Wii-Mote Cut out...work in progress

  dudeskidaddy • 10/09/2016 at 20:16 • 0 comments

  Everyone seems to have this problem...we've tried a few things, have some ideas and next steps.

  
  

  The Problem

  The Wii-Mote cuts out at high power / high load like going up a steep hill but is otherwise a great controller. The VESC works best with the Wii-Mote interface/app because it has many controls for acceleration/braking. We already have a working NRF remote, but it's big and clunky and because it talks to the VESC via PWM, the controllability suffers. We'd really like to fix the Wii-Mote problem.

  Background EMI & ESCs and cut-out.

  Not all radios are able to successfully operate in the electrically noisy environment near an ESC (VESC). ESCs produce high voltage/currents and broadcast energy across a wide spectrum in very close proximity to radio antenna and the wires connecting to them. EMI (Electromagnetic Interference) can take several forms. 1) Radio EMI can affect over the air signal between the remote and the receiver. 2) Wire EMI can affect the I2C comms between the ESC and radio receiver. Radio interference can be mitigated by physically separating the radio from the ESC. However the longer wires need to create a separation increases the likelihood of degrading the I2C comms. At this time, it is not known which effect dominates the problem specifically for the Wii-Mote though our experience with the NRF2401 puts the blame squarely on radio EMI. There is also the potential that neither radio nor wire EMI is not the problem at all, and that either a low supply voltage from the LIPO batteries to the VESC is created under high load or that the VESC is not supplying a steady 3.3v supply to the wii-remote receiver.

  What has been tried

  We've already built an EMI tolerant remote using an NRF2401 connected to an Arudino Nano via I2C. The Arduino was then connected to the VESC via PWM/PPM. The wii-mote however is directly connected to the VESC using I2C. At first, the NRF implementation was also failing under high load. We fixed the problem by moving the receiver about 15cm from the VESC. This would suggest strongly that the NRF problem was dominated by radio related EMI, not wire EMI. Can we make this same assumption for the Wii-Mote? Maybe. The I2C comms between Arduino/NRF is not necessarily the same as VESC/WiiMote which may have different voltage drivers, pull-down resistors and ADCs, any one of which could impact noise tolerance.

  Ways to determine what is happening.

  Option 1: Sniffing the I2C bus may provide a clue. The I2C protocol to the Wii-Mote receiver is a very simple 6-Byte payload with 2 commands (init and send-data) so viewing and interpreting these packets on bench logic analyzer should be easy. However observing garbage data would not rule out either radio or wire related EMI. Bad data could be the result of either one. Observing "good data" on the other hand would be very interesting as this would point to something internal to the VESCs I2C ADC. Lastly, it would be difficult to even make this measurement with bench-top logic analyzers as the cut-out condition can only be repeated while riding under load or using a bench load which we don't have. We'd really love to have that actually.

  Option 2: Move the Wii-Mote radio far (30 inches or more) from the ESC. If this works, the problem was clearly Radio EMI and no I2C EMI. If it doesn't work, it suggests I2C could still be the problem. It would be a good idea to provide battery power to radio during this experiment to isolate the experiment from any 3.3v power supply problem.

  Option 3: (3.3v Power problem) I've added 300uF cap the receiver VCC/GND but it didn't resolve the problem. This really only rules out small power droops. A definitive test (that I have not done) would be supplying an independent battery supply. 2 or 2 AA batteries for example.
  

  Option 4: Emulate Wii-Nunchk Remote I2C Slave. Convert our working NRF radio to emulate the Wii-Mote I2C slave protocol and connect via the VESC's Wii-Mote I2C port. This would take some time as I disassembled the...

  Read more »

• Battery Box Options

  dudeskidaddy • 10/04/2016 at 18:51 • 0 comments

  Custom 3-D Printed vs. Cast Aluminum Box
  

  Batteries will be 2x8000 mAh 5s Zippy Lipo (170 x 69 x 44 ) in (In series for 10s)

  The new board will be using the larger battery on the left

  Option #1: 3-D Printed Box

  I completed this cad drawing but I haven't printed it yet. I'll update when I get "1st plastic" I created this in OnShape which is a great, free web-based 3d CAD pkg. Feel free to copy it for your own use, but you might want to wait to see how well this thing fits together. Onshape Link to CAD Drawing

  There are 2 battery compartments that fix the 170x69x44 battery (+10mm space) and a 30x170mm space in the front compartment for wiring and placing the ports/adapters. The front face is ready for 2 XT-90s, 2 Xt-60s and 2 5s balance ports. It's about 3-5 mm thick depending on the part with added support on high-stress areas. (Wiring Schematic for wiring up 2 x 5s for independent balance charge, On/Off, hookup WIP) Overall Dimensions: 225 x 170 x 62 mm

  The bottom (the side that touches the bottom of the longboard deck when this is flipped over) is curved 10mm @ 70mm from the center to accommodate our curved deck.

  My nephew's printer can only make 215x70mm parts...not nearly big enough to create the top and bottom as single pieces. So we split the part into left/right halves. To help line them up for gluing, we added tabs/recesses. The top and front face are meant to come on and off so they attach withs screws. The model includes 3mm screw holes for self-taping screws. Ideally we could insert metal threaded sleeves (or nuts) to receive machine screws...haven't figured that one out yet. Honestly I have no idea how this is going to turn out. The print has to be fairly is precise, with no shrinkage, strong enough, etc to be a viable option.
  

  This shows the profile of the 8000mAh battery in its enclosure.

  Option #2 Cast Aluminum Box

  This box (From Mouser 1550WGBK) is JUST big enough to house these batteries (plus about 4cm of wiring space) but not a centimeter more in any dimension. It's the same one we've been using on board 1. The "W" in "WGBK" means water tight, which means it includes a rubber gasket. This is really important, not for water, but to keep the top from rattling loudly. The aluminum box is ready to go, much stronger and maybe more fire resistant than a 3D printed box. The only downside is that it's a bit heavier and square looking. We mount it with small rubber bushings to suppress vibration/rattle around 4 screws drilled through the bottom.

  Still...a few speed bumps manage to strike the edge of the box of our current board. This is one reason the 3-D printed box would be angled at the edge.

  Batteries almost fit.

  Need to take out at least one of these screw posts.

  Plunge cutter

  ...and this already was my favorite tool.

  Snug, but good fit. We might take out that second center post to make a bit more room for the batteries and padding. Still, be nice to have that middle screw in there to keep it from rattling.

• Second E-Longboard in the works

  dudeskidaddy • 10/02/2016 at 22:40 • 0 comments

  Work in progress. After 6 months a few hundred miles...ready to put all our improvement ideas to the test on our next board. It will be great having 2 boards and be able to ride together with the boys.

  Here is what we're doing differently:

  Trucks/Mount: Enertion: I absolutely love their mount we're now using on our current board because it just stays in place. I did several logs on this topic already. The rear mount can be a big source of trouble if it's not rock solid. My hat is off to guys who can weld their own mount. I looked into it and for the money and time, I'm happy to farm this one out and go buy the part.

  Rear Sprocket/Wheels: Again Enertion. The one-piece nylon rear wheel sprocket is well fitted to their wheels and IMO gives you a better result in terms of alignment and sprocket location than the "through-bolt" kind. If you use the Enertion rear-sprocket, I think you will also need to use their trucks. The half-round profile shape is pretty common but, they seem to have an extra long shaft (adds the width of a truck spacer to accommodate the sprocket). Don't know for sure though...maybe you can buy trucks elsewhere with the same profile and extended shaft.

  Motor: Enertion 190KV. I like our current 147kv Turnigy motor. However, it has a smooth shaft so mounting the front sprocket required grinding down 4 flat spots for set-screws. Occasionally these needed adjusting even with lock-tight. With a 175 lb rider whacking between forward and brake, those little set scews can take a beating, especially if the motor shaft grinding isn't flat. On the other hand, the enertion motor, while a bit more expensive, has a very nice key/tab thingy in the shaft that makes a perfect union between the shaft and sprocket. The sprocket is held in place with 2 small retaining rings...no set screws. They really did a nice job here. A very tight fit you need to tap in place gently with a hammer. A bit more $ but I think worth it. Happy we made this change. It's more KV: 190 vs 147 so we'll get more top-end speed. Gearing is higher too 16/36 vs 12/36. Not worried about low-end torque because we're bumping up the voltage from 6s to 10s, and 20C to 30C.

  
  

  Battery: 2x 8000 mAH 30C in series for a 10s. We'll have about 2x the range and power. I'll probably post our new power schematic. Haven't wired it up yet, but the idea is to be able to independently balance charge 2 5s batteries that when being used (not being charged) are connected in series...and NOT have to open up/unplug the battery case. I've read the VESC likes the 10s setup and may have reliability problems at 12s.

  Single Motor. Staying with single wheel for now. There are definitely times I wish I had a dual motor but we're just learning to ride and it hasn't been a big deal yet. Mostly you notice it loosing traction in very steep up/dn hills and when powering out of tight left turns. (motor is on right-rear). If I start commuting to work on this thing, I'll invest the the extra $350 bucks (additional VESC/Motor/Mount/Sprocket)

  Deck: We like having the kicktail on our current board, but just for a change of pace, we're trying this one that has kind of a boosted-board look. The lamiate is really flexible...very bouncy. Haven't ridden it yet, should be interesting. http://www.customskateboards.com/Custom-Longboards/Freeride-Longboard
  

• Remote Refinements

  dudeskidaddy • 10/02/2016 at 21:49 • 0 comments

  Now we have a few hundred miles on our board. We ride almost every day. Finally put some anti-skid down. Carved out the design and painted the board green under that spot. We've ridden so much the drive wheel is 1.5mm smaller than the others...might be time to rotate the wheels.

  Still working on putting the NRF based remote inside a Wii Nunchuck case. Took a while for a bunch of parts to arrive from China. USB-3.3v power/battery management PCB, LIPO, Smaller NRF package, switches etc. ATTINY85 has been tricky. Many nights staying up past 3:00 AM debugging the ATTNIY/NRF interface. Debugging options are pretty thin. There is a new NRF2.0 chip that just came out...has it's own micro inside...might be a better option. More homework.

  Nyko Kama Experience (good and bad)

  While working on our own nunchuck, we switched from our clunky, home-made NRF remote, to an off-the-shelf Nyko Kama wireless nunchuck+receiver a few months ago. Here is what we learned.

  The Good - Acceleration: The biggest improvement over our home-made remote is that the VESC is now managing acceleration/deceleration via the nunchuck 'app' rather than the ppm/pwm logic on our remote control. IMO there is no comparison. The VESC knows the wheel speed, so when accelerating after coasting, the throttle response and added torque is instantaneous. Just no way to implement this feature on the remote control because you need the wheel speed information to program this behavior. The Wii remote is light and feels good, battery life on 2 AAA has been great, the thumbstick is smooth and very easy to control.

  The Bad - Cut out: Like many others seem to have experienced, this remote cuts out under high load..ie goosing the throttle going up a hill, the VESC with shut down and resets after about 2 seconds. Really sucks. Still haven't figured it out. Some popular theories are

  1) 3.3v power drop to the receiver chip (update: 10/3 probably no)

  2) RF interference from the high-current VESC

  3) Vesc performing a low Voltage drop cutoff.

  4) Some other VESC software issue.

  As far as I can tell, the community is still guessing the cause...and no one has found a solution. Like others, I managed to get some improvement by shortening the wires between the VESC and the receiver, and moving the DC/AC power wires away as much as possible. But given the geometry of the VESC there is only so much spacing you can do. I'm planning on building a telemetry setup using arduino and a data logging chip...more parts from China...so we can definitively answer this. I'd ike to plot throttle position, speed, Battery voltage, 3-phase voltage, voltage to the remote.

  Final Conclusion: Wii-Mote is OK...not a final solution. Using the VESC's nunchuck app really raised the bar for performance over any remote control using the PWM input. Our next NRF remote...any remote...will absoltely have to use the nunchuck input protocol.

  (Update: 10/3/2016

  I added two 147uF capacitors to the Wii-Mote receiver VCC/GND last night but no improvement to the cut-out problem. Unless the supply voltage goes completely to zero (which I doubt), these should provide 1-3 seconds of current in a typical transient low-voltage situation. ( 1v drop * 294uF ~= .300C . 100mA draw (a total guess). 1v drop = 3 seconds, 2v drop is about 1.5 seconds to discharge the cap)

  VESC Timeout feature recommendation

  The VESC allows for setting a single value for braking force to be used in the event of a remote control time-out...ie if the remote battery dies. Better than nothing, but ideally it would implement a ramping break that would start small but progressively go to MAX breaking over say 5 seconds. If the remote cuts out on level ground, you are fine as is. But if a remote failure happens while going downhill...or approaching traffic...you are pretty much hosed. You don't want to set a single high value either because if you're not ready for it, max breaking will toss you off the board.
  

• VESC Finally Arrived

  dudeskidaddy • 07/25/2016 at 01:32 • 0 comments

  VESC

  From Enertion for around $100.00 After about 50 miles using our original Turnig 60A ESC (obviously with no brakes) our VESC finally arrived! Super excited to hook this up.

  Installation

  Installation was pretty straight forward. We added the female 4mm bullet connectors (because 4mm male connectors were already on the motor's wires), and hooked up the 3 wires to our arduino/NRF receiver. With the Caps, the VESC is a bit longer than most ESCs, but just fit in the battery box. It has no heat sink...not sure yet what (if anything) to do about that.

  Setup

  Without any setting changes, the motor was completely unresponsive. Poking around esk8 forums and playing around with the software, we finally got the many settings in line with our 6s battery * 147kv motor setup, adjusted the amperage for discharge and charge (braking), etc. I think the original VESC settings were set for Enertion's 10s battery, 190kv setup. All told, the setup took a bit of patience, a few hours and about 5 iterations (test runs) to get it right. There is very little in the way of documentation so some of the field/value pairs are a mystery. Best source of info are the message boards on esk8.

  Setup Speed Control: I initially thought something was wrong with the VESC's ability control motor speed based on throttle position because sitting on my bench, I could only get full stop or full power...not much in between. It clearly displayed the joystick position so we knew it wasn't the the PPM/PWM settings. But I think this is normal for a current-controlled system...and with no resistance on the motor, even a small current will quickly spool up to max RPM. After a quick road test (under load now), acceleration management was ok.

  FOC: We're using the new FOC mode...supposed to be super quiet and allow starts from a full stop...no pushing needed. It's a few MPH slower using FOC (vs BLDC)...not sure why.

  PPM/PWM

  VESC calls it PPM but I think they mean PWM. They are totally different things, but our arduino-based PWM output seems to work perfectly when selecting the PPM mode in the BLDC tool.

  Initial Testing

  Steep-Hill Torque: Noticeably less torque up our street's very steep hill. I suspect the old ESC was able to drag more current than the battery's 52A rating and the VESC holding to the 52A setting. Might also be related to slow-speed torque in FOC mode? Not sure yet. Getting plenty of acceleration torque on flat and medium hills when the motor is turning faster.
  

  Acceleration: From a standstill the acceleration is pretty brisk...took some getting used to but now we love it. No power lag coming out of a turn or hitting the gas after coasting...instant power. Fun.

  Braking: After 50 miles of using our hobby king ESC with no brakes...we really appreciate this feature now. We're able to go down hills, stop in traffic,...again, just awesome. Went on a 8 mile ride in high density traffic today on the water front in Portland and were able to weave in and out of people, slow down at will, stop at traffic lights, stay at a reasonable speed going downhill on the Tillikum Crossing bridge with people everywhere.

  Quiet: Amazingly quiet...in FOC mode. Practically zero engine noise...a huge difference.
  

  Starting from a dead stop: I'm so used to pushing a few times that it's hard to get out the habit...but from a dead stop it will go with absolutely no jitter or engine whine. Completely silent.

  What we'd do differently next time.

  Motor Shaft/Sprocket: Our 147KV Turnigy is nice, but because the shaft is smooth we had to file flat spots for the sprocket's set screws. This was fine with a normal ESC. Never had an issue with the sprocket moving after we cranked down on the set screws. But now that we're braking, the back and forth force is loosening the sprocket. Probably going to pay a bit more for Enertion's 190KV motor that has a recess in the shaft for a king-pin.
  

  Battery: Currently we have 2 6s batteries we run independently. Good setup for learning, goes about 12-15MPH. Plenty fast,...

  Read more »

• Man down

  dudeskidaddy • 07/19/2016 at 17:54 • 0 comments

  Wheel fell off during a ride

  Luckily I wasn't going fast or this could have really sucked. Bearing failed on the drive wheel and the wheel fell off...nut still attached.. Anyway, we think we know the story of what happened.

  What happened.

  • The mount will not fully tighten...and wiggles a bit no matter how hard you crank down on the nut.
  • Mount at some point made contact with the rear sprocket and made aluminum shavings.
  • Shavings get in the bearings.
  • Bearing fails
  • Wheel falls off

  Some pictures of the carnage.

  Bearing toast.
  

  This is where the rear sprocket was making contact with the mount. You can see where it's been worn down (silver ring). You might notice the wear pattern is a bit non-symmetrical...more wear on one side of the sprocket. This shows how the sprocket is not perfectly aligned to the wheel. I've made a previous log about this problem, but this is best I can align the them.

  Lots of aluminum powder came out of the wheel hub when I took off the sprocket.

  After about 5-8 miles, the heat shrink is pretty much toast from the slight wiggle in the mount-trunk union. Just can't get a perfect, permanent fit. Heat shrink probably isn't the best material for this...sucks actually.

  Conclusions:

  So this is our first "test" board. We plan on making 3...one for me and 2 more for the boys. It's been a really great learning process and we've had lots of fun. What's next?

  • This motor mount just can't be made to have a permanent fit...requires constant adjustment after each ride. Doesn't matter what material you use to improve the gap. Tried everything including aluminum shims.
  • Rear wheel sprocket setup is OK...so far hasn't needed much adjustment after getting it fit
  • We'll be trying the Enertion setup next time.

  
  

• NRF and Attiny not playing well together

  dudeskidaddy • 07/11/2016 at 23:21 • 0 comments

  Can't go Nunchuck until the NRF and ATTINY play nice.

  Our current NRF and Arduino Nano-based remote works well, but is big and clunky.

  Before we can make a nice one inside a wiimote, we'll need to get the smaller and lower power ATTINY85 (or the larger ATTINY84 with more IO pins) working.

  ATTINY / NRF is not working for us. We're trying everything we found online, including...

  • Using the same NRF libraries and code that work for others
  • Everything wired up correctly
  • Using nice wires with good terminals, no jumper wires, no shorts or opens.
  • Good power supply to both the Tiny and NRF
  • Using plenty of power caps, 100uF, 10uF .1 uF. Not seeing any power droop, see good signal transistions.
  • Attend is supposed to be running at 8mHz

  How do you know the Attiny's 8 mHz clock is working?

  Run a simple blink sketch with a 1000ms delay using "Tools->Clock->8mHz" If the LED blinks every second, then the Tiny Clock is working at 8Mhz. If on the other hand, the LED blinks for 8 second and off for 8 seconds, then it is still running at 1mHz.

  void loop() {

  // put your main code here, to run repeatedly:

  delay(1000);

  digitalWrite(3,HIGH);

  delay(1000);

  digitalWrite(3,LOW);

  }

  
  

  To fix this...Burn Bootloader?

  From Arduino IDE simply selecting "Tools->Clock->8mHz" tells the chip what the clock frequency is supposed to be so that things like timers still work. For example calling delay(1000) actually takes 1 second. But selecting 8mHz from the menu doesn't actually change the clock frequency! Turns out that to actually change the ATTINY clock frequency you have to use an Arduino as an ISP and select: "Tools->Burn Bootloader". This sets the ATTINY fuses to actually speed up the clock. Running the above blink program should yield 1-second blinks.
  

  Confirmed @8Mhz...but still not working.

  We're seeing a difference on the SPI Logic Analyzer between the Attiny and Arduino implementation. The numbers being passed are completely different and the SCK frequency is 4x slower with the ATTINY. The SPI protocol has the "master" control the SCK so that shouldn't be a problem...interesting though.

  The following logic analyzer output (top row digital and again on the bottom row in analog) is showing a 1 mHz SCK frequency for the ATTINY and NRF combination.
  

  The following logic analyzer output is showing a 4 mHz SCK frequency for the Arduino and NRF combination. Interesting how the clock is now too fast for the Saleae's relatively slow ADC to pick up the transitions. (the bottom row doesn't match the top).
  

  Serial Print on ATTINY

  We're not taking advantage of this...mainly because all the pins are taken up by the NRF. Not sure, but maybe we can get software Serial.Print working on the ATTINY84 (which has many more IO pins)

• NRF2401 Power Capacitor Experiment

  dudeskidaddy • 07/01/2016 at 16:21 • 0 comments

  Quick aside: Prototyping with crappy jumper wires is bad. By accident we discovered our entire NRF-problem was caused by our combination of female-female and male-female jumpers. We're investing in a better supply of wires with all combinations of terminations.
  

  Probing the power and SCK lines
  

  The NRF is thought to brown-out occasionally and/or the signal transitions are too slow to be detected unless you put a 10uF capacitor across the VCC/GND pins of the NRF. Don't want to go into too much detail here, but what we were hoping to see when we probed the power and signal lines is 1) Constant voltage on the power supply that never drops below 3v and 2) crisp, quick (i.e. vertical) transitions for the signals.

  Results

  Above is a snapshot of the POWER (yellow) and SCK (blue) lines. At this time, there is a single 10uF tantalum cap across the NRF2401 power/gnd pins. As the SCK transitions from low to hi, the power drops significantly (to 2.76v) and the clock rise/fall slope is pretty bad. Pretty nasty looking: big droopy power and slow SCK transitions. We think the NRF is just barely operating...almost browning out and at the very margins of signal integrity.

  Next we tried these NRF2401 with an NRF breakout board (above) with no external capacitor. This PCB has its own on-board power supply (5v to 3.3v) and surface mount capacitors of unknown value. However in testing, the power supply and on-board caps seemed completely inadequate to supply steady current to the NRF and absolutely needed the extra 10uF capacitor to work.

  Next, we swapped out the 10uf Cap for a big 100uF. Above we see the large, slow power droops are much improved, but now we still see these little rapid, sharp power droops. This is probably because the 100uF cap is too slow to supply current for sudden bursts in load.
  

  Finally we added 2 more smaller caps to handle these quick power loads: 100uF Tantalum, 10uF electrolytic, 0.1uf Ceramic. Pretty clear the NRF2401 needs a little babysitting on the power supply because finally the power signal and SCK lines look pretty good: very little power droop and sharp transitions on the signals. This was a fun exercise and let us play around with a lot of the features of our new Rigol toy. So again, the single 10uF still works but maybe the 3-cap setup might help somewhat when battery power is on the low side....another experiment?

  Here is the NRF, NRF break out and the 3 capacitors.

  
  

  
  Taking directly to the NRF

  We found the following code to return the status of the NRF unit. It was nice to directly read the status in detail rather than simply not receiving a message on the receiver.
  

  RF24 myRadio(7,8);
  
  void setup() {
  ...
  // provides a way for print to link to Serial.println
  fdevopen( &my_putc, 0);
  // public method in NRF library that prints lots of setting details. 
  // should not be all 0x00 for example..should have real data.
  myRadio.printDetails();
  
  }
  
  // provides a way for print to link to Serial.println
  int my_putc( char c, FILE *t) {
  
    Serial.write( c );
  
  }
  

  ...and here is what we get from printDetails() on the broken NRF2041s. A bunch os 0xff.... The one good NRF we have returned the proper encoding for each setting. One thing to check easily is the Address Bytes since these are directly set by the NRF library's setAddress() API

  STATUS = 0xff RX_DR=1 TX_DS=1 MAX_RT=1 RX_P_NO=7 TX_FULL=1
  RX_ADDR_P0-1 = 0xffffffffff 0xffffffffff
  RX_ADDR_P2-5 = 0xff 0xff 0xff 0xff
  TX_ADDR = 0xffffffffff
  RX_PW_P0-6 = 0xff 0x7f 0xff 0xff 0xff 0xff
  EN_AA = 0xff
  EN_RXADDR = 0xff
  RF_CH = 0xff
  RF_SETUP = 0xff
  CONFIG = 0xff
  DYNPD/FEATURE = 0x7f 0xff
  Data Rate = 1MBPS
  Model = nRF24L01
  CRC Length = 16 bits
  PA Power = PA_MAX

• NRF2401 Alive!

  dudeskidaddy • 06/23/2016 at 17:06 • 0 comments

  Finally we got our 2401s working!

  Pros:

  • Range seems to be much better than the 433 MHz transmitter we have been using so far. 50 feet vs about 6 feet. This means less dropped packets, faster update rate, more options for larger transmission payloads (more buttons).

  Cons:

  • No external antenna on the 2401. The ESC seems to interfere with the radio at high power settings. Everything is packing into the same aluminum enclosure...have to find a way to work around this problem...maybe move the radio to the outside of the box.
  • NRF2401 Uses 5 pins. So can't use my existing stock of Attiny85 (6 available besides vcc/gnd) to drive this and still have pins left over for buttons. Right now we using an Arduino Nano which needs 5v and presents a bit of a battery problem...using 5v means 4 AA...so the remote is big and heavy. Ideally my remote will work on a single 3.6v LIPO cell. To do this, we'll need to move from the Arduino micro-controller to to Attiny 84 micro or the 85 that has more pins.

  How we finally got it working:

  • Using this updated NRF24 library and not this NRF library from Arduino. The pin mapping used by the updated library is completely different.
  • 10uF cap soldered directly on the PWR/GND pin of the NRF24
  • Arduino Nano 3.3v on-board regulator seems to have sufficient power for the NRF2401 even in MAX transmit mode. Even works with the notoriously high output resistance 9v battery!

  Code: A few details

  The Payload Optimization: We're sending a 3 byte payload over the air. 2 bytes for potentiometer's 16-bit integer and 1 bytes for the state of 3 buttons. (cruise control, emergency brake in case the potentiometer fails and maybe something for the future like lights, a horn, turbo mode...who knows). This kind of compression is probably overkill but it's more fun and might save a bit of battery power on the remote.

  Setup Mode: ESC setup requires moving the throttle from full high to full low in a second or two...our calibrated throttle response is too slow for that since we've programmed it to take about 6 seconds. We created "Setup mode" to bypass the spool up/dn and directly send the throttle position to the ESC. In this mode it can go from 0 to full power in about 1 second! For safety, no matter what button you push on the remote, setup mode only works in the first 10 seconds of operation.

  Throttle Response, Braking: In testing under load, we found the first 25% of throttle doesn't produce much acceleration. So we changed the spool up to go from 0 to about 25% throttle pretty quickly...under 0.5 second. Ideally we're just talking about a a non-linear response. Could have come up with a nice smooth polynomial for this, but we're still prototyping and just picked a few values we thought would work.

  Cruise Control: If cruise button is pressed, throttle only works when the stick is full aft/fwd. Brake button still active.

  NRF2401 Transmitter. 1 Pot value (0-1023) and 3 buttons (bool)

  /*
    NRF2401 - Arduino Nano
     1 - GND  to GND 
     2 - VCC  to 3.3V 
     3 - CE   to D7
     4 - CSN  to D8
     5 - SCK  to D13
     6 - MOSI to D11
     7 - MISO to D12
     8 - floating
  */
  
  #include <SPI.h>   
  #include "RF24.h"  
  
  RF24 myRadio (7, 8); 
  byte address[8] = {"abc123"}; // Pick Your own unique address here 
  byte data[3] = {0,0,0}; // 1st 2 bytes are pot, second byte is the 3 buttons (3 bits)
  int pot_pin = A0;
  int pot_val=0;
  int button1_pin = 2;
  int button1_val = 0;
  int button2_pin = 3;
  int button2_val = 0;
  int button3_pin = 4;
  int button3_val = 0;
  
  void setup()
  {
    //Serial.begin(115200);
    //delay(500);
    //Serial.println(F("Starting..."));
    pinMode(pot_pin,INPUT);
    myRadio.begin();  
    myRadio.setChannel(181);  
    myRadio.setPALevel(RF24_PA_MAX); // Not sure if this is needed yet, MIN maybe ok.
    myRadio.openWritingPipe(address);
    delay(1000);
  }
  
  void loop()  
  {
    unsigned pot = analogRead(pot_pin); // potentiometer
    data[0] = (byte) (pot & 0xFF);
    data[1] = (byte) ((pot >> 8) & 0xFF);
    bool b1 = digitalRead(button1_pin); // button1
    bool b2 = digitalRead(button2_pin); // button2
    bool...

  Read more »

View all 16 project logs