Home arrow Forum arrow Archived Forum
FreakLabs Forum
Welcome, Guest
Please Login or Register.    Lost Password?
Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking (1 viewing) (1) Guest
Go to bottom Post Reply Favoured: 0
TOPIC: Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking
#2562
Ian (User)
Apprentice Freak
Posts: 1
graphgraph
User Offline Click here to see the profile of this user
Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 10 Months ago Karma: 0  
This thread discusses the Content article: Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking

The Arduino approach opens many possibilities for ease of use and making it pervasive.

Energy conservation by monitoring & control seems to be a prime driver for the wireless sensor industry uptake... Any thoughts on an Energy Harvesting board?

The 'Install & Forget' appeals! Zero batteries just adds value to whole smart energy market.

Also, in human nature terms by example, when my house smoke detector battery needs replacing and continuous bleeps I do what majority of all people do... I pull out the battery and then it takes me months to remember to buy and replace with a new one.
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2563
Akiba (Admin)
Admin
Posts: 1245
graph
User Online Now Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 10 Months ago Karma: 25  
Actually, that is on the drawing board. It's really more of a solar cell/supercap type board but with battery backup. I'm going to need to do some mods to get the power down low though.

For an indoor device, I would probably just use a TI MSP430 w/no energy harvesting circuitry. Those things can last couple years on 2-AAAs. There just aren't many good options to harvest indoor ambient energy, that I know of...
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2610
Neuromancer (Visitor)
Click here to see the profile of this user
Birthdate:
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 10 Months ago  
I don't know if you have seen this chip but I think it would be the next iteration of your board. ATmega128RFA1. You would have to figure out how to use the chibiArduino stack with this but it would be a pretty awesome single chip solution. Might save some cost as well.
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2615
Akiba (Admin)
Admin
Posts: 1245
graph
User Online Now Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 10 Months ago Karma: 25  
Yes, I have about a 100 of those chips just sitting on my shelf. The problem is that those chips are sold out and heavily backlogged. Since the supply isn't stable, I don't really want to introduce them into a product. Otherwise, if I sell out and then tell people they need to wait 6 months before they're back in stock, it doesn't look very good. Those chips are perfect for WSN too...*sigh*
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2639
Lyle Merdan (User)
Apprentice Freak
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 0  
Just got my Freakduino-Chibi boards the other day. I soldered them up last night.

For a hardware change, I recommend changing the layout of the holes for the stacking headers and you might even go further and do this for the other through hole devices.
http://www.sparkfun.com/tutorials/114

I've got a board I made where I used this technique and it works REALLY well to hold parts in place while soldering.

On the instructions page, another tip for soldering the headers is to put the headers in place and then if you have an arduino shield around, place that on the headers to hold them straight.

Next on the instructions, you should tell the users to install the software into their home directory / documents / arduino / library directory and remove the version and date info from the folder name to comply with the arduino IDE - otherwise it complains.


I'm sure there will be a few more things as I dive deeper into it.
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2640
Akiba (Admin)
Admin
Posts: 1245
graph
User Online Now Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 25  
Thanks for the tips. Yeah, through hole is always a pain in the ass to solder down. I like the reverse (or mirrored connector) technique but the one I often use is the technique towards the end of my assembly tutorial.

Also, I totally forgot that I had the software inside my directory already when I made the tutorial. Thanks for that tip. Need to update the assembly and usage pics to show where to put the files.
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2641
Lyle Merdan (User)
Apprentice Freak
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 0  
I'm having fun with the chibiduino. Thanks for a great product.

Could you document the proper switch and jumper settings for these situations:

USB power
AA backpack power
AA through JST
DC jack

Just to make sure no magic smoke is accidently released from the board.

I also ask because if the jumper is set to DC and connected to USB the red pin 13 LED blinks... Oh the silkscreen for the 1 of 13 is voided because of the via. It looks like you could nudge a couple of traces to move the via towards the center of the board. The same goes for a couple of other labels voided by vias. hmmmm "Voided by Vias" sounds like a band name.

Also I decided to poke around on the FTDI, it has the max power set at 90ma. Is that an issue if I draw more than the programmed current? I used the FT_PROG program from the FTDI site to do the poking around. Looking at the Arduino Duemilanove it is also set for 90ma. So I'm not sure it matters.

On the subject of the FTDI, is it possible to draw power from the the battery backpack or JST and use the USB for serial communication in order to get a configuration as close to what one might use for deployment power usage yet keep the serial communication for debugging? What would the proper jumper switch config for that if it's possible?

Note that the Arduino IDE serial monitor does not work with the cmdline example #4. I tested on Win 7 and on OS-X 10.6.

I haven't tried an alternative to the arduino IDE serial monitor on the mac yet.

I'm wondering if it would be best to zero out the EEPROM of the 328 and then set a default short address. Maybe expand on that and follow the Uno practice of programming in some kind of serial number at the end of the EEPROM....

I also think it would be great if you layed out the pins in use by the wireless in a sample sketch header.

Maybe just steal this right from the datasheet:
/*
Two pins on the analog input connector are not available for use except for standard digital I/O. These are pins Analog 2 and Analog 3. Analog 2 controls the sleep mode and Analog 3 controls the chip select for communications between the microcontroller and radio IC. If the wireless functionality is not used, these pins are available as standard digital I/O but not as analog inputs. If possible, its best to avoid using these pins. If the wireless functionality is being used, the SPI bus is also required to communicate with the radio. That means that digital pins 10-12 (PB3 to PB5 or MOSI, MISO, and SCLK) will be dedicated SPI pins.
*/

Lyle
 
Report to moderator   Logged Logged  
 
Last Edit: 2010/12/09 21:36 By StandardRockets.
  The administrator has disabled public write access.
#2649
Akiba (Admin)
Admin
Posts: 1245
graph
User Online Now Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 25  
QUOTE:
Could you document the proper switch and jumper settings for these situations:

USB power
AA backpack power
AA through JST
DC jack

Just to make sure no magic smoke is accidently released from the board.


No problem. That's a great idea and I'll be adding it to the documentation.

QUOTE:
Also I decided to poke around on the FTDI, it has the max power set at 90ma. Is that an issue if I draw more than the programmed current? I used the FT_PROG program from the FTDI site to do the poking around. Looking at the Arduino Duemilanove it is also set for 90ma. So I'm not sure it matters.

On the subject of the FTDI, is it possible to draw power from the the battery backpack or JST and use the USB for serial communication in order to get a configuration as close to what one might use for deployment power usage yet keep the serial communication for debugging? What would the proper jumper switch config for that if it's possible?


There is a 3.3V regulator on the board rated for 1A so there shouldn't be a need to pull any power off the FTDI. One of the reasons I added a beefy 3.3V regulator is because most of the more recent chips run at 3.3V. So I think its important to have circuitry that supports this.

As for drawing power from the USB (for the FTDI) while battery powered, yes this is possible. The FTDI is powered separately from the rest of the circuitry. It gets its power directly from the USB power no matter what the switch setting is. So if the switch is set to battery power, then the USB would still power the FTDI. This is because I figured nobody would use the FTDI chip without a USB connection

QUOTE:
Note that the Arduino IDE serial monitor does not work with the cmdline example #4. I tested on Win 7 and on OS-X 10.6.

I haven't tried an alternative to the arduino IDE serial monitor on the mac yet.


Yeah, one thing that I'm not too fond of is that the Serial Monitor won't allow the "Enter" key to be pressed. In my command line code, the Enter key (carriage return) is the signal to parse the command that was entered.

If you're on the Mac, drop into Terminal and find the device name. Once you know the name of the device, you can just use the command "screen <device name> 57600" . That will open the device using "screen" as a serial terminal emulator and at a baud rate of 57600. To exit screen, you press <Ctrl-A> and then <d>.

QUOTE:
I'm wondering if it would be best to zero out the EEPROM of the 328 and then set a default short address. Maybe expand on that and follow the Uno practice of programming in some kind of serial number at the end of the EEPROM....


Not sure if I should program in a default short address. Short addresses are usually nicknames and aren't globally unique. There is a chance that in the future, I will buy a block of 64-bit addresses from the IEEE. If I do that, then I can program the boards with a 64-bit address that I can guarantee will be unique. It's similar to an Ethernet MAC address and that's the original idea behind the long address (64-bits).

QUOTE:
I also think it would be great if you layed out the pins in use by the wireless in a sample sketch header.

Maybe just steal this right from the datasheet:
/*
Two pins on the analog input connector are not available for use except for standard digital I/O. These are pins Analog 2 and Analog 3. Analog 2 controls the sleep mode and Analog 3 controls the chip select for communications between the microcontroller and radio IC. If the wireless functionality is not used, these pins are available as standard digital I/O but not as analog inputs. If possible, its best to avoid using these pins. If the wireless functionality is being used, the SPI bus is also required to communicate with the radio. That means that digital pins 10-12 (PB3 to PB5 or MOSI, MISO, and SCLK) will be dedicated SPI pins.
*/


That's a great idea! I'll need to modify my sketches, and I'm planning to add more. Those should be coming soon, but I'm in the middle of an interesting project at the moment. If I can get it to work, I think it would make the Freakduino boards very useful. Not sure if I can pull it off, though. If I do, you'll be hearing about it
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2650
Lyle Merdan (User)
Apprentice Freak
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 0  
Great info!

Would you like me to email suggested updates for the next release of software / docs or would you like me to keep posting? As I dig further I've got some questions and suggestions to make things more arduino crowd friendly.
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2651
Akiba (Admin)
Admin
Posts: 1245
graph
User Online Now Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 25  
I think its best to post the suggestions up publicly. It might inspire other ideas from people and I like keeping dialogs open as much as possible. Also, your suggestions would probably be useful for other people designing boards and shields for the Arduino crowd
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2654
Lyle Merdan (User)
Apprentice Freak
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 0  
Cool! I gotta get them out of the head because they stop other thoughts from happening.

So for chibiSleepRadio, how long of a delay (if any) should there be before attempting a transmit?

Also have you thought of doing an implicit chibiSleepRadio(false) whenever a transmit is done?

And on that thought, what about storing a sleep state before a transmit and restore that state following a transmit and all ACKs are complete? This feature is targeted towards nodes that primarily transmit...


Regarding the IEEE address, I'm wondering if there could be some borrowing from the ethernet library defined address when it's used. Just a thought in it's infancy at this time.

I've added some propoed documentation of valid ranges to the chibiUsrCfg.h. I filled in some of the min/max values on speculation. Please double check my work as I know enough to be dangerous and I speculate some of those ranges are wrong.

With regards to improving shields, I'm suprised no one has proposed any kind of label standard for pins used by a shield. Most people will attach a shield and any external devices before diving too far into software. So if a board / shield like yours had a $ instead of labels on analog 0 and 1, that would be a warning to users those are not availible for general use. Then in the case of SPI pins or I2C pins, use a # to designate that they are used for that protocol.
File Attachment:
File Name: chibiUsrCfg.h
File Size: 12233
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
#2655
Akiba (Admin)
Admin
Posts: 1245
graph
User Online Now Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 25  
Oh, that file is really nice. I just added it to my subversion repository. It should show up on the next release. Not sure when that will be, but probably in about a month's time. I'll be adding chibiArduino support for the AT86RF212 soon which runs on the 868 Mhz (Europe) and 915 MHz (North America) bands.

I like how you used the name "chibiduino". It has a nice ring to it and I'm considering changing the name of the board to it.

Regarding some of the other comments:

QUOTE:
So for chibiSleepRadio, how long of a delay (if any) should there be before attempting a transmit?


There shouldn't be any delay required. In the driver's chb_sleep() function, I set the state to RX mode on wakeup. The chb_set_state() function has a delay inside of it that blocks for the specified time required for the PLL to lock.

QUOTE:
And on that thought, what about storing a sleep state before a transmit and restore that state following a transmit and all ACKs are complete? This feature is targeted towards nodes that primarily transmit...


I think that for now, I'm going to leave the power management up to the user's sketch. People that play with the power management usually know what they want to achieve. I'd prefer to keep the driver as simple as possible, unless obvious patterns emerge that might be better handled down there.

QUOTE:
Regarding the IEEE address, I'm wondering if there could be some borrowing from the ethernet library defined address when it's used. Just a thought in it's infancy at this time.


Do the Wiznet chips come with pre-programmed MAC addresses? I had thought that there was no MAC address that came with them.

Incidentally, I've tossed around the idea of buying an OUI (Organizationally Unique Identifier) and then parsing out small blocks to individuals. An ethernet MAC address is just made of a 24-bit OUI and then an additional 24-bits internally unique to the company.

I'll probably have to let this idea gestate for a while, but anyone can pretty much do it. With 802.15.4, it's quite nice because the IEEE OUI is 24-bits but the 802.15.4 extended address is 64 bits. That means you get approximately 40 bits of unique addresses or roughly a trillion addresses.

Anyways, lemme know if you have any other comments or suggestions. I'll be integrating your suggestions into the docs and the example sketches. The additional descriptions you added to the user config file were awesome. That one is definitely going into the release folder
 
Report to moderator   Logged Logged  
 
Last Edit: 2010/12/13 06:54 By cjwang.
  The administrator has disabled public write access.
#2657
Lyle Merdan (User)
Apprentice Freak
Posts: 8
graphgraph
User Offline Click here to see the profile of this user
Re:Introducing the Freakduino-Chibi, An Arduino-based Board For Wireless Sensor Networking 3 Years, 9 Months ago Karma: 0  
Akiba wrote:
QUOTE:
Oh, that file is really nice. I just added it to my subversion repository. It should show up on the next release. Not sure when that will be, but probably in about a month's time. I'll be adding chibiArduino support for the AT86RF212 soon which runs on the 868 Mhz (Europe) and 915 MHz (North America) bands.

I like how you used the name "chibiduino". It has a nice ring to it and I'm considering changing the name of the board to it.


Please take a minute and double check the ranges I stuffed in there to make sure they are all good.

So for the name chibiduino, sorry but I accidentally started referring to the board as that. I didn't mean to ruin the millions of dollars and tens of thousands of hours spent by FreakLabs on branding. The name is what kind of stuck in my head for some reason. With other names like freeduino, sanguino and seeeduino out there the chibiduino seemed to just be the name I started referring to it as.


QUOTE:
Do the Wiznet chips come with pre-programmed MAC addresses? I had thought that there was no MAC address that came with them.

Incidentally, I've tossed around the idea of buying an OUI (Organizationally Unique Identifier) and then parsing out small blocks to individuals. An ethernet MAC address is just made of a 24-bit OUI and then an additional 24-bits internally unique to the company.


So the ethernet shields did not have a pre-programmed MAC. But the second gen shields have a sticker on them with a MAC: http://arduino.cc/en/Reference/EthernetBegin

Parameters

mac: the MAC (Media access control) address for the device (array of 6 bytes). this is the Ethernet hardware address of your shield. Newer Arduino Ethernet Shields include a sticker with the device's MAC address. For older shields, choose your own.


The thought train behind this is if an ethernet shield is in use, I'm just thinking of reducing code / defines space...

For the docs, I think you should add a note to the chibiSleepRadio function that there is no delay needed between wake up and transmission.

Now I'm at work so I can't really dig around too much but if in polling mode and there happens to be data in the receive buffer, and then the radio is put to sleep, then woken up later and there is no more data rx'd OTA before a receive is done, will that buffer still be populated or do you accommodate for that in the driver?
 
Report to moderator   Logged Logged  
  The administrator has disabled public write access.
Go to top Post Reply
get the latest posts directly to your desktop