Playing with a Photon (2)

phot-with-bat1Continued from page one …

So, I’ve found the minimal, steak and potatoes development environment for the Photon.  Great!  I need to make some other notes.   The particle-cli nodejs program can be used to configure the WiFi on the board, so that the board can connect to the local access point, and run as a web server on the local net (at least in my setup).  But, in this mode, the particle-cli program is just a wrapper on a serial communications program.  The exact same WiFi setup can be accomplished using a serial comm program like minicom.

  • $particle serial wifi   (using particle-cli nodejs program)

I just start minicom and set up the serial connection with /dev/cuaU0, 115200,8,1,N serial config details, plug the the board into the PC with a USB cable, and press the tab key.  Note: the /dev/cuaU0 device was used when I was accessing the Photon with my FreeBSD environment.

At such point, one can configure the WiFi simply by pressing “w” (smallcase):

  • w
  • SSID:
  • myssid <enter>
  • Security:
  • 3 <enter> (this is WPA2)
  • Password:
  • mypassword <enter>
  • Thank you! You’re credentials have been stored (sic) …

Several other keys return other results:

  • v
  • Result: Firmware version 0.5.1
  • i
  • Result: DeviceID=xxxxxxxxxx

Likewise, “s” is for sysinfo, and “m” is for the MAC address, etc.

So, the steak and potatoes environment for developing Photon firmware is gcc-arm-none-eabi + dfu-util + a communications program.  That’s just like most other MCU board dev environments. The extra items (particle-dev, atom, particle-cli, etc) have potential purposes though.  Let me explain.

In the Particle.io world of IoT things, devices are spread around the world, and managed by a particle cloud.  That’s the emphasis on all those other tools, that are beyond the steak and potatoes minimum.  Those tools are geared to interact with the particle cloud, to manage communication, programming, access control, datalogging, and other things all from the cloud.  While interesting, that’s not my purpose for the Photon, so I’ll be sticking with meat and potatoes, and a local net WiFi server, that serves up my sensor data in a *very* easy way to digest … much easier and less expensive than the other options at this point, IMO.

One Photon board, at small cost and trouble, could connect to many sensors, aggregate the data, and send it periodically to a master controller.  After each data transmission, the Photon could sleep (actually – it could deep sleep) – dropping its power consumption down to about 175 microamps.   After some period of time (an hour?), it could wake up and repeat the data aggregation and transmission.  This is currently my theory, but I’ve yet to implement it to see how well it could operate.  With my tri-pack of NiMH batteries, how long (potentially) could the remote sensor operate?  Let’s calculate it:

The NiMH pack has a capacity of 2500 mA hours, at 1.2×3 = 3.6 volts.

The booster, which regulates and boosts the voltage to 5 VDC, is a reduction factor, as such:

  • 80 mA x 5/3.6 x 1.20 = 133 mA  (very approximate)

What’s that?

Well, when the Photon is transmitting, it will average 80 mA of draw, when the supply voltage is 5 VDC.  Because the converter runs at only 80 percent efficiency, the current from the batteries is increased by the 1.20 factor.  Because the voltage on the output is higher than the total battery voltage, the current from the batteries is increased by another factor of 5/3.6.  So, while transmitting, our little board will be consuming around 140 mA (ball park figure).  This assumes the 80 mA figure (from datasheet) is correct.

  • Now, it’s easy.  A 2500 mAh pack will run 2500/133 = 18.75 hours.

Booo.  Not even a day!  But wait, remember we’re going into sleep mode for 59 minutes out of every hour.  So, we use only 1/60’th of that power per hour.  So, our battery should run 18.75 x (60/1) = 1125 hours.

That’s  ~47 days!

OK, we’ve ignored the sleep mode current.  My bad.  Let’s subtract that out of the total:

  • 1008 hours = 42 days (very approximate).

We’ll see how this works out in practice.  I’ll need to do some soldering first.

One of the things about the Photon is how well it communicates with only its RGB LED.  It has a different color for every little thing.  Here’s a quick list that is mostly applicable to meat and potatoes developers:

Blinking BLUE:

By holding the setup button down for three seconds, the mode should shift to “listening mode” – verified when the RGB LED is flashing (with medium speed) – a blue color.  In this mode, one can connect a USB cable, and use minicom to configure the WiFi on the board.

Blinking (rapidly) BLUE:

By holding the setup button down for ten seconds, the WiFi configuration should be cleared, verified by a rapidly blinking BLUE color.

Blinking YELLOW:

By holding both buttons down, then releasing the reset button while keeping the setup button pressed, and continuing to hold the setup button thru the point where the unit flashes magenta, and until the point when it flashes yellow, DFU mode will be entered.  In DFU mode, the board can be flashed with new firmware (system + user program).

Breathing Magenta:

Breathing Magenta is “connected in safe mode,” and is entered with the same procedure as DFU mode, except the setup button is released sooner (when the unit is still blinking a magenta color). While blinking magenta, the Photon can be receiving a new application over the air (OTA).

Blinking GREEN:

If blinking GREEN, and the unit has WiFi credentials, then it’s trying to connect to the internet.  If it’s BREATHING the green color, then it HAS connected to the internet, or is running a program.

Blinking RED:

Blinking red is an error condition.  The blinks are in a code:  S.O.S, and then a number which is the error number.

Breathing Cyan:

Breathing Cyan, the unit has connected to the cloud.  I think this is the case, but there is much conflicting info on the net.  I haven’t used this mode, so can’t verify.   I do know that my unit “breathes” GREEN when it’s serving my HTTP connections over WiFi.

The last item (cloud) won’t be of interest for me, on this project.  BTW: I have seen varous numbers put out for deep-sleep current draw, some as low as 100 uA.  I have’nt tested this yet, but WILL!  If it’s only 100 uA, then our unit might run the better part of three months on our tri pack NiMH power!

Read More

Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.

Note: the Photon referenced in this post is manufactured by the folks at particle.io, and this site and author are not related to them in any way. PHOTON is a trademark of Particle Industries, Inc

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s