Xbees are nice small part used to help small stuff, like Jaluino Bee, communicating together. These are wireless modules, implementing ZigBee protocol. This is quite a tough one, luckily using XBees themselves remains something accessible for the mere mortals. While you could use Bluetooth modules, you may still be interesting in using Xbee as they can join together to build a multi-point network. That is, having several modules talking each others, not just point-to-point communications.

Xbee in transparent mode

I’ve been using two XBees for month, in transparent mode. In this mode, point-to-point is implemented. This is basically a serial over-the-air link, it works very nicely, and most importantly, reliably.

I’ve been using Xbee series 2 only, as series 1 is becoming deprecated. While series 1 works right out-of-the-box, series 2 requires you upload a specific firmware. I strongly suggest you follow this great tutorial, explaining all the steps in details. (note this PDF file can be found on many different sites, I wish I could credit the author but nothing except his first name — or last –, Cairn). I also strongly suggest you buy two XBee adaptors like the ones Cairn is using, you can find some for few bucks on eBay. And you’ll save a lot of time in the end.

So, this is transparent mode: in AT mode, a “Router / End Device”, typically your Jaluino Bee, is talking to a “Coordinator”, typically your PC, collecting data. This is not what we want here, but that’s a start, and that’s a first step before going further so make sure you’ve been able to have your xbees talking each other, through a point-to-point link.

Entering XBee API mode

Now, what if you add a third Xbee ? Well, that’s what I’m facing right now, as I want to add another monitoring station, collecting data to some IOT platform like Pachube. So, this third Xbee is going to cause a lot of pain if plugged as-is over your point-to-point link. Basically, Coordinator (PC) will receive characters from the other two xbees, without knowing which is talking. Conflicts, collisions. You could adapt your communication protocol, where the Coordinator would poll others Xbee, but you’d then implement retry on error, End Devices wouldn’t be able to talk without being explicitely asked to…

That’s what API mode is made for. In the mode, XBees can send data frame to each other, without any risk of collision. In order to achieve this, we need to access XBee through API commands. This isn’t transparent anymore, this adds complexity, but not much compared to what it brings on the other hand.

So, for this first part, we’ll make sure our XBees are properly configured. We won’t use any Jaluino Bees for now, just two XBees connected to a PC.

Configuring Coordinator

Plug a XBee on an adaptor, in the same configuration used in previous transparent mode tutorial (see PDF file link above). Wire this adaptor to USB-to-serial adaptor (again, see PDF tutorial).

My setup: on top, USB-to-serial converter, connected to, on bottom, XBee adaptor.

Open X-CTU, you should be able to see a USB serial port. Select it (mine is COM4), run “Test / Query”, to make sure you’re able to talk to your Xbee.

Now switch to “Modem Configuration” tab, click “Read”. In the dropdown list, select “ZNET 2.5 COORDINATOR API”. Click “Write”.

Selecting Coordinator API firmware

Go back to PC settings, run “Test / Query”. It fails. Why ? Because now we need to tell X-CTU it should access XBee in API mode. Check “Enable API”, and re-run test. It works.

Using “Enable API”, we can talk to Xbee again

We now need to fine tune Coordinator configuration, specifically setting “Escape mode”. Back to “Modem Configuration”, click “Read”. Scroll down and set “API enable” to 2. This means some characters will be escaped, basically those used to form data frame. This ensure there won’t be collision between user data and API specific chars. Click “Write” again. You can also set a “Node Identifer” string, like “COORD”.

API Enable = 2 means some chars will be escaped. While testing comms on “PC Settings” tab, you’ll need to check “Enable API” and “Use escape chars” to talk to your XBee !

Important: note the following parameters, we’ll need them later.

Coordinator:

• Serial Number High: 13A200
• Serial Number Low: 40301109

Configuring End-Device/Router

We’ll proceed the same, except we’ll select “ZNET 2.5 ROUTER/END DEVICE API”. Make sure you have “Enable API” set to 2.

End Device/Router:

• Serial Number High: 130200
• Serial Number Low: 4054F82F

Testing API Mode

You have one Coordinator, one End Device. Plug them on their respective adapter. You should now have two Serial USB port, one for each. In the following test, Coordinator will send data to a specific End Device.

We’ll use the following python script in order to test our setting. These scripts use the excellent python-xbee library, you’ll need to install it: http://code.google.com/p/python-xbee/

• receive_samples.py
• send_samples.py

Edit “receive_samples.py”, and change PORT to whatever your port is. Mine is COM13 for End Device (remember, End Device will receive data).

Now edit “send_samples.py”, change serial port as well, and then change the value of DEST_ADDR_LONG. Here’s mine:

DEST_ADDR_LONG = "\x00\x13\xA2\x00\x40\x54\xF8\x2F"

Gasp,what is this ? Well, first, this is the destination address for End Device we want to talk to. That is, its “serial number high” concatenated to its “serial number low”. Have you noted these values ? Great. This address is 64-bits long, so you may pad values with 0s if needed.

My serial number high is 130200. I need two more bytes to have 32-bits, so that’s 00130200. My serial number low is 4054F82F. No 0s needed. So, final address is:

"001302004054F82F"

This is in hexadecimal format. We need to tell python about this. So we add “\x” in front of each byte:

"\x00\x13\x02\x00\x40\x54\xF8\x2F"

That’s it!

Now run the sample on different cmd shell.

It works !

You can try to switch address to End Device will talk to Coordinator. Plug Coordinator first and run receive sample. Then plug End Device, don’t run python sample. In this configuration, you’ll notice something interesting: when End Device is up, Coordinator will receive a data frame about it. Particularly, End Device sends its own address, something interesting to build generic host application where devices auto-register to the Coordinator Xbee.

Devices sends information to coordinator about itself when powered up

What’s next ?

In next part we’ll see how to plug this on a Jaluino Bee, and make it talk to the PC. A final part will be dedicated to receiving data from PC.

Any questions ? Join Jaluino forums.

I made a wish on Seeedstudio’s Wish platform: have Jaluino Bee board manufactured and listed at Seeedstudio, the next big step for this project.

If you want to support Jaluino Bee, vote for this whish, it could come to reality!

Cheers, Seb

New v2.1 PCBs arrived so it was time to build a new board, testing this (not so) new design. This new version is mainly about being able to select widely used part. v2.0 suffered from a rare (or at prohibitive price) SD card holder, this new v2.1 fixes this, as well improving several other little fixes (see improvement list on this post).

Building instructions are very similar to v2.0 so I’m not going to explain all of this in details, but the only the differences. If you basically follow v2.0 instructions there shouldn’t be any issue. Here are Jaluino Bee v2.1 related files:

• Schematic
• Board top view
• Board bottom view
• BOM

This is Bee v2.1. Not much differences… Looking closely on this side, you’ll notice mini-USB has been replaced with a micro-USB connector (see this forum post). There was an issue with this connector, but on the design itself, but on the parts I ordered: they have small bumps, theoritically requiring holes on the PCB, which has none… So I had to cut those bumps in order to get this connector soldered. Bee user Trev reported he had micro-USB connectors without such bumps, so that’s really just a matter of selecting the proper part.

Micro-USB connector is a little harder to solder than micro- one, since the pads are smaller. Nothing undoable, pads are well exposed to solder tip, that shouldn’t be a problem.

Beside micro-USB, on the left, is C1 a 1µF capacitor, initially designed as a tantalum cap, and finally using a 0805 form factor. v2.1 fixes this by providing smaller soldering pads (note for the curious ones: Bee usually used 1206 SMD form factor, on which you can use both 0805 and 1206 components. I used this to let user choose, in the end, 0805 resistors and capacitors are much cheaper. Still 1206 pads make them easy to solder).

Finally, last main change is SD card holder. This is still push-push type one, but it now has pins clearly exposed outside the case (pins were under the case on previous one, make it quite hard to solder). This time, it’s both easy to solder, and also to source the component.

Building Jaluino Bee v2.1 is quite straight forward, no surprise. Tests went pretty well too. I use several test files designed to limit the number of extra components to the minimum (well, none), using onboard LED to notify tester whether it’s working or not:

• Blink a LED: jal – hex – video
• Real-Time clock: jal – hex – video
• Serial: jal – hex
• Serial USB: jal – hex
• SD-Card: jal – hex – video

]]> http://jaluino.org/building-jaluino-bee-v2-1/feed 0 http://jaluino.org/new-pcbs-available-finally?utm_source=rss&utm_medium=rss&utm_campaign=new-pcbs-available-finally http://jaluino.org/new-pcbs-available-finally#comments Fri, 24 Feb 2012 18:54:22 +0000 sebastien.lelong http://jaluino.org/?p=105

At least new PCBs arrived! Chinese Spring holidays combined with an error in one Gerber files caused this delay.

Interested ? Have a look at jaluino forums:

• Jaluino Bee v2.1 PCBs: here
• Mini-Crumboard v1.0 PCBs: here
• Mini-ProtoGrove v1.0 PCBs: here

Follow instructions here in order to get some of these.

Note: Bee v2.1 and ProtoGrove designs aren’t tested yet (though it usually goes pretty well). Few kits (probably ~$10) should also come soon once tested, stay tuned (and subcribe to Batches forums)

After several month working of Bee improvements, new PCBs for Jaluino Bee v2.1 have been ordered from SeeedStudio. Several other PCBs have been ordered as well: some more Mini-Crumboard, and a new shield, Mini-ProtoGrove. I’ll post more about all of this when I get PCBs and build new Bees. In the mean time, you can have more details in forums and pre-order PCBs:

• Jaluino Bee v2.1
• Mini-Crumboard v1.0
• Mini-ProtoGrove v1.0

This is a recurrent issue: “my SD card won’t work, I tried the sample, I triple check hardware, it just won’t work”. The main problem here it’s hard to get feedback and report it to jallib library’s author (namely Matt). Different issues were previously found:

• some brands seem to work better than others. For instance, SanDisk is reported to work nice, whereas there seems to have troubles using Kingston’s.
• some SD cards will require pull-up resistors, some won’t.
• and SDHC, high capacity SD card, aren’t supported.

When experiencing SD card for the first time, it’s hard to understand where the issue comes from. You first have to check hardware, make sure connections are OK, add pullups resistors on at least on /SS pin. I’ve recently experienced a hardware issue, whereas I knew for sure it had previously worked. The problem was coming from a non-working connection on microSD socket. Soldering pins again fixed the issue.

Once hardware is checked, you’ll have to make sure your software is properly written, proved to work. Luckily you’ll find fully tested HEX files for Jaluino Bee board on project’s SVN (see hex files). Check correspoding uncompiled Jal files in order to know what’s expected. If your board is following standards (same MCU, Xtal,…), these HEX samples must work. If not, well, check your hardware. If it’s still doesn’t work, maybe it’s coming from your SD card.

You should now run the reporting sample, named “jaluino_bee_sd_card_report.hex” (click on “View raw file” to download it). This is a Jaluino Bee sample that will print, through serial (9600 1N8), some debugging informations while initializing SD card. While this won’t fix your issue, it’ll at least help understanding where you’re stuck, helping developpers fixing the bug (hopefully).

Following is an example showing a successful SD card init:

Basically, sd_init() is called, it tells the card it’ll use SPI protocol. It resets the card, and the card replies “ok” (0×01). It’ll then wait the card to be ready. This means until the card doesn’t reply “00″, it’s not good. In this case, “00″ was returned after seveteen “01″. So far so good, the init is done. More subsequent information is then displayed. Typically, in this case, it’s been reported by Matt that when the card replies “FF” instead of “01″ after resetting the card, it’s mostly a hardware issue. I can confirm this from my last experiment

On the other hand, using the same program with a SDHC card gives:

Unfortunately in this case, we’re getting stuck while waiting for the card to be ready. We’re constantly reading “01″ as a response, while we should have “00″. (careful, don’t mess up with “reply” and “response” terms here. “reply” is the first returned value after reset, while “response” are the returned values while waiting for the card to be ready).

If you’re experiencing SD card problems, please run this sample on your Jaluino Bee board and report your results. Let’s hope with enough data, from different brands & card types, we’ll find how to handle them all !

When I designed first versions of Bee, I mostly used Sparkfun Eagle library, as an habit, and browsed eBay on the other side in order to choose components: one that’s available in Eagle and cheap enough on eBay. By this time, I selected a microSD socket Push-Push type:

These were easily found on eBay, at a decent price, I ordered 5pcs (~$5). Since then, these aren’t available anymore, alternatives sources are much more expensive, something like $3 to $4 per socket. This somewhat kills my low cost approach… Another drawback is pins are under the case, which make this part hard to solder, probably the most difficult one.

Now I have few PCBs left, but no more microSD socket and only half complete kits.

Maybe another socket could be used ?

I recently bought this type: microSD socket with hinge (hinged typed). Price is even lower: ~0.5$/socket.

Good news: this kind of socket can be adapted to Bee v2.0 layout, with minimal changes. Here how it goes…

This is mostly about the two GND pins at the bottom. If you try to place this connector on the PCB, you’ll see these GND pins are very closed to the shield connector’s hole:

But…

• interestingly, the bottom left pin is near GND connector ! Since socket case must be tied to GND, this pin can be soldered with GND hole without harm.
• the bottom right pin is near C5 pin. Using PIC18F27J53, this pin is a USB pin and isn’t exposed to shield connector. Again, it can be soldered without harm. If using PIC18F25K22 (this is my case here), this pin is exposed as this MCU isn’t USB-capable. So the microSD GND pin must be cut in order to make sure it won’t touch to the shield connector.
• on the upper side, another socket’s GND pin is near a GND pad. Can be soldered to it.

If you’re about trying this, don’t trust me and double check connections Give feedback as well.

And in the end, Push-Push socket will have to be replaced in another PCB batch.

You may have heard about “Internet Of Things”, platforms mixing hardware and software projects to publish and share data accross the web. The idea is to have some hardware collecting data, and publishing it on a website. One successful example, open source & free, is ThingSpeak, used here in this post.

So, Jaluino Bee is cheap (~$10 if you build your kit yourself) and that was one main goal while designing it. A reason is the cheaper it is, the more you can put Bees as things in the internet. This is the idea here: collecting electrical consumption from a power device and publish it on ThingSpeak.

Flashing LED (between the two blue buttons)

How does it work ? My electrical counter device had a LED flashing every 1W/h. A photo transistor is used to detect and count these flashes, using interrupts. RTCC peripheral collects timestamps and an alarm triggers another interrupt type every minute. Data is sent over serial, through a bluetooth module.

Photo transistor mounter on power device (ok, quick & dirty)

Photo transistor with small plastic cylinder to focus light from LED.

Bluetooth module plugged on Bee

Application shield, from a Crumboard shield (prototyping area on which you can solder components)

The whole solution: Bee + Bluetooth + Shield, powered by USB

On a server, a python script is receiving data through serial, format it and publish it to ThingSpeak using its API. Python script also initializes RTC date & time on Bee’s side.

Results: on this video, white LED is triggered by flashing LED on electrical counter device. Blue lights are coming from bluetooth module, meaning it’s alive.

Data published to ThingSpeak can be viewed thanks to a very nice web API:

One data point every minute

Does it work ? More or less. The main problem here is the bluetooth link. Server often lost connection, definitely loosing data collecting, mainly due to the distance. Even if few meters away, signal doesn’t seem to be strong enough. A true Xbee module should be tested in order to check performances. As improvement, in order to fully exploit Bee’s capabilities, SD-card should be used to store data in case server isn’t available, then publish them when back. On the previous graph, there seems to be two bad data point showing an extreme consumption, probably not realistic. This probably means flash detection needs some kind of debounce logic (interrupts can be triggered multiple time for one flash…). Finally, features should be added to firmware in order to better configure Bee’s behavior.

More later, for sure…

This is a quick & dirty recipe to build Jaluino Bee v2.0 from a kit. Build your kit at your own risk, I’m not responsible for any damages, you’ve been warned. Twice.

Here we go.

	So, this is typically how a home-made kit looks like…
	Here are the big parts composing the kit: PCB, pin headers, crystals, SD card holder, USB, jumpers, and PIC18F27J53.As opposed to…
	… small, very small SMD components Those are stuck on a paper showing the Bill Of Material (BOM). Make sure to get components, one by one. You won’t be able to identify them (eg. capacitors) once they’re far away from their label.(Thanks to Trev for this great idea)Note: you can access the full BOM in PDF following this link
	Make sure to have the full Jaluino Bee v2.0 schematic somewhere, you’ll have to refer to it quite frequently.
	Here’s the top side of PCB. Refer to this image if you have trouble reading PCB labels.
	Same for the bottom side.
	OK, here we go. You’ll need to thin soldering iron, and ideally a hot air station, particularly useful when soldering the SD card holder.But for now, we’ll build the power supply part. Start to solder micro USB connector. Make sure there’s no shorcut between pins. On this photo, the two most left pins are shorcut, no good…
	Congrats, soldering USB connector isn’t that easy. Let’s continue.Solder C7 tantalum caps (yellow), D2 Schottky diode, AMS117 3V3 voltage regulator, D1 protection diode.Note: tantalum have a bold line showing their anode. It’s not the cathode, as with diodes for instance. Silkscreen for tantalums shows a curved end, this is where the bold line side should go. Zoom the photo as needed.
	Don’t forget to solder 250mA resettable fuse on the bottom side.
	Solder LED1 (power supply LED) with its resistor R5.Solder both 1×3 pin headers, and put jumpers on them, like on the photo. Be careful.The first jumper on the left is to select whether you want the board to be powered using a battery (using the two big pads, refer to top side image), or USB. Putting the jumper as shown on the photo will select USB as power source. This is what we want The second jumper is critical. It selects whether you want to bypass voltage regulation or not. In our case, since USB powered, we have to, we must use voltage regulation, so we put jumper as shown. If we had powered the board using 2xAAA 1.5V barrery, we could bypass regulation as 3V would be enough to power the PIC. Don’t touch this jumper unless you’re sure about what you’re doing, you can burn your board otherwise.
	LEDs are polarized, make sure to respect polarity. LEDs show a small green dot reprenting the cathode (the bar at the top of triangle/arrow).(zoom the photo, you’ll see the green dot…)
	Are you sure everything is good ? Great, let’s give a try. Red LED should light. Make sure you have 3V3 across the board (point pin headers bottom, using GND and Vdd. Also check on PIC’s pads).
	Celebrate this momentum, and admire your red LED. Have a break, breathe gently and deeply.Let’s continue.Solder R1, R6, C13 and push button. This is the reset circuitry. Add decoupling cap C4, LED4 and R20.Then solder C3, C6, C12, onboard LED2 and R2. Then C1, C2, C9, C10, C5.About C12: this is 1µF cap, 0805 form factor, but pads are greater. Just make sure to add enough solder to create connection.
	OK, drink some water, relax yourself, we now have to solder PIC18F27J53. Not that hard, much more esier than USB connector for instance. As usual, make sure there’s no shortcuts, and make sure pins are exposed to pin headers. Careful: no all pins are connected to headers, for instance, USB pins and Xtal aren’t exposed by default.
	The hardest part: SD card holder. Hard because pins are below the component itself. This is where a hot air station is very helpful. But you can still doing this using a soldering iron, and approach the tip below the holder.You can postpone this step if you like. You won’t be able to use SD card (obviously) but you’ll be able to check everything else is ok.
	SD card holder soldered, good job (or not…)You can also solder pullups resistors. These are for SD-card. Sometimes they are useful, sometimes not. Start on the safe side and solder R11 and R12, these are /SS pins for SPI/SD-card and SPI/extra memory chip (if you want to add it later)
	Now solder crystals Q1 and Q2. Make sure Q2 won’t touch surrounding C9/C10 caps
	Almost done !Solder C11 on the bottom side.
	Now configure your board with solder jumper. Solder SJ7 and SJ1. Here were connecting Vusb to Vdd, and select pin A5 as SCK pin in SPI protocol.You can also see on this photo how C12, the 1µF cap, is soldered on big pads.
	If you have a Xbee (and something using the same form factor), make sure to first plug Xbee pin headers before soldering them. Those headers aren’t symmetrical, so if you solder them “randomly” your Xbee may fit as well as it could.So plug your header on your Xbee, position the whole on the board, solder 2 or 3 pins on each pin header, remove your Xbee, and finish soldering.If you don’t have any Xbee modules on the like, I suggest to postpone this step, until you really need it. These pin headers are also very hard to unsolder without damages.
	OK, done ! Celebrate again !Top side should look like this.
	Bottom side should look like this.
	Board is ready to be tested. It can be programmed with PicKit2 for instance, but it needs to be upgraded (dat files).

Where to go now ? You can check Hex files on Jaluino Google Code SVN repository. I’ve been succesfully tested them: http://code.google.com/p/jaluino/source/browse/#svn%2Ftrunk%2Fsamples%2Fhex

Please also give feedback, on Jaluino Group: http://groups.google.com/group/jaluino

I hope you’ll have as much fun as I have designing and using this board.

Jaluino Bee gets listed on Dangerous Prototypes, post your best & fun project and win a Jaluino Bee board !