JeeNode frequencies and signal quality

A question arose on the HackerSpace Brisbane mailing list about the supported frequencies of the JeeNodes. I was under the impression, in the vacuum of contrary information, that the units I had would work at least to some extent in all the supported frequencies (433, 868 and 915 MHz), although it is difficult to make a single radio that can do that. I was under this impression because I had tested such with the RF12demo on the units when I first unpacked them.

It turns out that because I bought them at the actual JeeLabs Shop, in Europe, I got the 868 MHz versions, rather than the 915 MHz version sold at Modern Device. This might be problematic.

Anyway, I did a number of tests to determine the suitability of each frequency with the modules I have.

Testing more thoroughly with the RF12demo again, I determined the following radio capabilities:

• changing both to any of the 3 frequencies allows communication both ways (including ack)
• changing one to 868 and the other 433 allows data 868 -> 433 but not the other way (and no ack reply)
• sending from 915 cannot be received by either 868 or 433

This indicates all frequencies work, or at least some kind of shared delusion of using the same frequency.

Then I tested the relative signal quality of each frequency. I wrote a sketch that spams my car about every 50ms (it has an echo function for pinging and tests just like this) and reads the echo reply. I ran that on the USB JeeLink attached to my laptop used the highly scientific approach of walking around the house with it. I had it print out a dot for every send, and an R for every receive, so the ideal output looks like this:
.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R.R

... and so on.

• 915 was ok, in the same room it got all the packets, and I could get through two or three walls and still receive a significant number of packets.
• 868 was awesome. I went all over the house and hardly dropped a packet. In fact I had to get the laptop halfway into the fridge before I started losing more packets than I sent! ...R...R.R.R.R....R..R... 
• 433 was disappointing. It lost packets within the room and lost significant amounts just outside the door!

Note that this was all with unoptimised antennas. Default length of about 90mm. According to this talk page, 868 should be at 82mm (pretty close), and 433 at 165mm, which might explain its poor performance. I don't think 1/8 wave works very well. 

 

 

Car fully working with JeeNode

I pulled out the old RBBB Arduino clone, and hastily blue-tacked the JeeNode in its place. I left all the breadboard wiring in place in case it didn't work and I had to revert to the RBBB. But, success! It was a bit fiddly jumping all the wires from their otherwise neat ribbon cables into the JeeNode ports, but here it is:

The small ribbon cable with the black lead goes to the wheel motor controller, and the larger cable with red is for the pan/tilt servos, IR gun and has room for expansion.

So I've connected up everything, and it successfully goes forward, back, left, right, moves the camera, shoots and measures the battery voltage! Just as responsive as before! Only this time with better range! More on that in another post.

Saggy reprap parts :(

I often leave my stuff in the car, in the sun, while I'm at work, when I'm heading to HackerSpace Brisbane that evening. This must have happened on a particularly hot day:

 

The base of the pan/tilt mount is badly warped. The tilt doesn't work very well any more because the distance is greater, so you tilt up halfway and it starts going down again. Infinite sadness.

Do I put it on a flat surface and hit it with a hair dryer to get it back in shape? Do I just print a new part? I planned to design a new one with a support that went all around instead of just at the front. That should help with warping. Also a smaller base would be better, and the corners on this one catch on the servo wire, so it should be more rounded.

JeeNode working!

After quite a while porting my arduino code to use the jeenodes instead of serial/xbee, and figuring out which pins on the "ports" map to digital pin numbers, I got it to work! I can control the pan/tilt mount remotely! (that's all I've tried so far) And it's quite acceptably fast - in fact pings hover aound 54ms!

The main challenge with porting the code was that instead of just throwing data at the serial port and letting the xbees deal with it, I have to think about how to break it into packets, and which packets I really need to send and which I don't. There is also the issue of sometimes having to wait to send data, which might become a problem later. For now I have two methods, one says "send it now if you can, else drop it" and the other says "try to send forever". If the channel was tied up, it would just freeze up there. Obviously there will need to be some middle ground, if I run into problems.

I also had to write code for the JeeLink (the usb dongle, which is basically just a SMD AVR and antenna), to make it appear to be a plain serial connection for the frontend software. It was easiest if the frontend changed as little as possible (not at all, actually). In future it will be extended to provide the sender node ID and so on. This may probably become a central server node that directs all the traffic to the clients.

I had to figure out the mapping of pins to the existing arduino pins I was using so I could plug the servos into the right ports. Also there are only 4 digital and 4 analog-in ports provided on the JeeNode, so I was worried that I was already using all the pins I had available. I looked at the JeeNode diagram and the arduino diagram and painstakingly mapped it out. Basically the RF12 module steals 5 of my digital pins, two of them PWM. But some pins are mapped to the I2C and SPI/ISP connectors also available on the JeeNode, and to the INT pin on each Port. So I should be able to recover 3 digital pins, 2 of which are PWM, and two more analog-in pins. So that provides enough room for some additional things I want to do :)