Jot Update Backup

RobotShop · December 18, 2013, 7:32pm

UPDATE: 12/24/13

Well, I don't know what to say. I think I'm going to take a break from this build for a bit and focus on finishing the Overlord project with the Dot Muncher.

I discovered what was causing my problems with the NRF24L01. It wasn't the voltage-regulator. It was the 1uF 0805s filtering the regulator. I replaced the unknown capacitors (ones bought off of eBay) with some from Digi-Key that were rated 25v. This fixed the problem and I had the Jot communicating nicely as I had hoped.

Of course, that wasn't the end of the problems. I discovered the HCM5883L board was shorting, I believe, everytime I programmed the board. It's pissing me off. I've burnt four compass boards and two Arduino Pro's over the issue (smoked around $15 in parts). It has something to do with the HCM53883L I2C lines feeding backward through the board whenever the Arduino goes low. It causes the voltage-regulator on the HCM5883L board to pop almost right away. Of course, it does slight damage to other parts of the connected boards. I didn't know it at the time, however, I believe this was the reason the filtering capacitors were damaged, the backward current.

Stuff Burnt on the Pyre of Stupidity -->

That's not the only issue. The code I've got together for the NRF24L01 doesn't play nice with the HCM5338L library.

But I can't tell how to re-write the code in a way they are happy with each while the f'in boards keep burning up. Sigh.

Nevertheless, I think my next step, when I've got my gusto back, will be to make a complete schematic of the Arduino Pro Mini, Little Helper Board, and the HCM5338L. I figure the first two I have schematics for already, and I have enough HCM5883L boards to pull the components off and reverse engineer the PCB.

Still, I'm a little depressed. I'm feel like I'd been better off making the boards myself. At least then, I would know exactly how they are strung together and could only blame myself for issues.

I also feel like Frits needs to put together a "Robotics Fail of the Week" so I can be it's first highlight. Man, even looking at that picture now makes me feel like I suck at life. Oh well, I'm going to list the good stuff I've learned from this.

Reverse current is a bitch--low-drop diodes are your friends.
I have put together code that makes the NRF24L01 have closer to Bluetooth functionality. Though, it doesn't like being in the same code as the Wire library.
Cheap parts are require you be time rich.
NRF24L01 isn't really meant for streaming data. I knew this to begin, but I didn't understand how it really plays out in the code. The NRF takes a lot of code management. Unlike other devices that are hardware managed or SoC. This makes the NRF highly sensitive to what else your code is doing. In my case, running servos, communicating over I2C, and doing floating point math. As I progress in this build, I feel I'm taxing the NRF's functionality beyond its ability.
It is better to learn the circuits of all boards connected to yours. It might initially take more time, but in the end save time and money.
If I fail it something, although looking ridiculous is not fun, documenting the failure makes me feel better. Like it meant something. Even if that something is, "Hey world, I'm an idiot." :)

UPDATE: A Jot of Trouble

I didn't want to float this post until I have something working to update, but I missed writing for a change. I've been working on the little Jot frequently over the last few months. Yet, I keep running into problems. The NRF24L01s are acting silly. One day they work, another they don't. I guess we can't make woman jokes now that Roxanna77 is here? (If you read this Roxanna, just wanted you to know I had to make sure my wife didn't read this post, it'd been hell in my house).

I have reworked the servo board (v.9.5) to include a double 90-degree header. One set is to attach the servos, the other is to attach the Compass (HMC5883L). This was meant to make the hardware more compact, modular, and keep the compass level for a better reading. Oh yah, and I burnt a few HMC5883Ls trying to connect them with crappy braided wires.

Also, I've added solder-jumpers to tie the 3.3 SOT-23-5 voltage regulator's enable pin to either high or low, depending which one I mistakenly buy.

On the top side I've included an SMD voltage divder running straight into analog pin A3. My intention is to allow the Jot to keep an eye on its battery voltage as a way of sensing how "hungry" it is.

I've added a 3.3v pin on the new double 90-header, in case I've a 3.3v sensor elsewhere on the bot. I dunno, I was trying to use all the extra pins I had.

Of course, since I've learned how to tent vias, I've also tented the vias on the board with hope I'll save myself a fateful short or two.

I'll eventually try to replace those bulky headers with what I've affectionaly begun to refer to as "Those short, round headers." I like these little headers because of how utterly small they are. Of course, they are small but the bulk of their body does not make it through thicker PCBs. This is due to the point flaring closer to where the plastic header is. This flare prevents the short-rounds from sinking through the typical header hole on most boards.

But, I've got calipers, Eagle CAD, and OSHPark, so I made a little library of header holes that will allow these pins to slip neatly through the board and mate with short-rounds on the other side. I sent off to OSHPark for a sample, so I'll report back when I've tested them for effect.

Now, for what has kept me from moving forward with this little damn bot: A cheap voltage regulator.

On my original version of the servo board (by the way, I refer to it as the Little Warmie Helper board or LWH board) I had used a different voltage regulator that cost more. The only difference I found between these were the output, the first I used putting out 200mA and the second 150mA. I really didn't think this made a difference, given what I could find in the datasheet. I know there are passives effecting the power consumption, but it's the only info I could find (datasheet, pg. 8) The NRF24L01 was using around 11.3mA for the transmitter and 13.5mA for receiver. Even though I didn't know the power-consumption of the passives I believed I was well within the range to use the cheap 150mA voltage regulator. But, experience has proven otherwise.

This is where I ask the professionals to come in and tease me about missing something simple.

The only theory I could invent, given my limited understanding of electronics, is the NRF24L01 only used 11.3/13.5mA in an amp hour, but the burst use exceeds the constant 150mA of the cheap regulator? I don't know. I'm at a loss.

Of course, this is pure speculation. I'm currently out of higher output voltage regulators (I should have some more by the end of the week). But, I can leave the NRF24L01 in place on my LWH board and solder on jumpers to the 3.3v and GND pins and get the NRF24L01 to function properly. This makes me believe the fault lies directly with the inadequacies of the voltage-regulator and not my board design (though, it's inadequacies I'm sure are glaring).

Anyways, this is where I am with the little Jot.

A couple of notes. I have a backup design of the Jot that I'm working to get cheaper than $25, which uses BLE (yes, those HM-10s I'm in a love-affair). Also, I decided if I was to get serious about the Overlord project I'd probably do better turning it into a Python module, which I've been doing in silence and is around 90% done. I'll try to have it up before the end of the year. I need to finish several functions.

UPDATE: Progress on NRF24L01 code for working between PC, Hub, and Robot.

So, here is my attempt at a swarmie build. Not much here yet, simply a personal build log until I get an iteration cheap enough, then, I'll start incorporating them into the Overlord project.

I have to bow to Bajdi; those little NRF24L01 take a lot more brainpower than simple ole' Bluetooth. I tried for some time to write my own code that would send and receive bytes to or from the other node. After a little of hair pulling I gave up and started reading other's code. I came across Robvio on the Arduino Forums who had some rather nifty code that I left nearly intact.

#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
RF24 radio(8,7);

// Radio pipe addresses for the 2 nodes to communicate.

const uint64_t pipes[2] = {0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
//for Serial input

String inputString = “”;         // a string to hold incoming data

boolean stringComplete = false;  // whether the string is complete
//NRF Packages

byte SendPackage[32];

byte ReceivePackage[32];

boolean sending=0;
void setup(void)

{

//

// Print preamble

//
Serial.begin(9600);

radio.begin();

// optionally, increase the delay between retries & # of retries

radio.setRetries(15,15);

radio.setPayloadSize(32);

radio.openWritingPipe(pipes[1]);

radio.openReadingPipe(1,pipes[0]);

radio.startListening();

//radio.printDetails();

}
void loop(void)

{

//check for NRF received

NRFreceive();

//check for Serial received (or filled by NRF)

Serialreceive();

}
void serialEvent() {

Serial.println(“Event”);

while (Serial.available()) {

char inChar = (char)Serial.read();

inputString += inChar;

if (inChar == ‘\n’) {

stringComplete = true;

}

}

}
byte NRFsend(String NRFPack = “”){

NRFPack.getBytes(SendPackage, 32);

radio.stopListening();

radio.openWritingPipe(pipes[0]);

radio.openReadingPipe(1,pipes[1]);

bool ok = radio.write(SendPackage,sizeof(SendPackage));

if (!ok) Serial.println(“NRFerror”);

radio.startListening();

unsigned long started_waiting_at = millis();

bool timeout = false;

while ( ! radio.available() && ! timeout )

if (millis() - started_waiting_at > 200 )

timeout = true;

if ( timeout )

{

Serial.println(“NRFerror”);

}

radio.openWritingPipe(pipes[1]);

radio.openReadingPipe(1,pipes[0]);

}
void NRFreceive(){

if ( radio.available() )

{

//byte ReceivePackage[32];

bool done = false;

while (!done)

{

done = radio.read( &ReceivePackage, sizeof(ReceivePackage) );

delay(5);

}

radio.stopListening();

inputString = ((char *)ReceivePackage);

stringComplete = true;

radio.write( “1”, 1 );

radio.startListening();

}

}
void Serialreceive(){
if (stringComplete) {

if (inputString.startsWith(“T:”)) {

NRFsend(inputString.substring(2));

}

if (inputString.startsWith(“S:”)) {

Serial.print(inputString.substring(2));

}
inputString <span style="color: #333333;">=</span> <span style="background-color: #fff0f0;">""</span>;
stringComplete <span style="color: #333333;">=</span> <span style="color: #007020;">false</span>;

}

}

The way this code works is much like a software and serial simulated Bluetooth module.

To send serial data it goes like this, you type something with a prefix code, T for transmit and S for serial print, and ending with a newline character (\n).

For example, typing the following in the terminal on module A:

T:S: My message \n

Will send “My message” to the other module B, then, it will print “My Message” to serial line on the module B.

If you type,

T: My message \n

This will transmit “My message” from module A to module B, but it will not be printed to the serial line on module B.

I’ll let you guys look the code over and tell me if I can improve it for what I’m doing. Right now, I’ve tested it with some basic Python code to send a serial message to my hub (Arduino Uno and NRF24L01), which relays it to the robot (Arduino Pro Mini and NRF24L01).