Great work. I gave it a little thought and this is what I came up with as feedback. Again have a great vacation.
Frankly I think WOR should be a sleep argument to the SL command not a mode, as the previous mode should be unchanged. This is the issue I have with the current low power, it really isn’t a mode like the others. Is Low Power really a mode, or simply better controlling of the radio subsystem. In WOR Low Power I do not see that the users should notice any change in behavior.
(Is this correct? If it is I will argue for it being the normal state.)
I view it as there are several general states here.
Reduce Power until event occurs, where event is anyone of
WOR
Interrupt received.
Serial received.
To me this is not a mode, but a efficiently wait state.
Hibernate, ignoring Local events, other than watch dog if independently enabled.
WOR
WatchDogTimer if independently enabled.
External circuit trigger.
This is sleep on radio, node is a remotely controlled slave.
Sleep.
Radio traffic ignored.
WatchDogTimer if independently enabled, or other external wakeup
Serial data ignored.
Shutdown for until locally kicked or watchdog.
There is one more option to complete things, but its value is not as clear to my fuzzy thinking.
Turn off radio, but leave the 168 going. That is this is
SleepRadio, but save state.
168 is uneffected. Radio is pwr’ed down until wake. This is the best candidate for a MD to me. This is really Mode radio power downed, and until an ATMD is issued to wake it up and set the resumed state it is powered down.
Is there a need for IDLE radio, not sleep, not WOR, but just stay in the IDLE state? This condition is implied by transmit mode, where the radio goes to this state when there is no data to send, but does this state as a mode need to exist? This is leave the radio up and calibrated, but not doing anything. It is clear that this state is used, and may speed the transition to other states. I am just not clear if the speed up it offers is enough to expose it in the model.
@icing
I was reading the datasheet, and I noticed it claimed 2 analog inputs. This is confusing me because, 1 10 input, adc7 is mapped, but adc6 the other does not appear to be brought out. Now from reading the 168 datasheet 6 of the PortC pins can be made analog inputs, 8 bits, but that doesn’t add up to 2. Can you clarify what is meant here? I am simply curious as Hans has things working well enough I am getting read to try so configurations with sensors and the like.
Also since somebody asked I was thinking of connecting the i2c interface in a slave config. the pins are mapped so it should fly, but I thought I would double check.
Okay that means I read the wiring diagram correctly please add this to things to fix on the documentation. It claims 2 analog inputs. Although If you do a new ref, I would recommend bringing out the other port.
vacation was great, thanks for all the good wishes !
ideally the Wait state (atmega in IDLE, RFbee in WOR) would be the default state, however WOR is less stable than Receive (else TI would certainly have done the same thing ) I’d rather leave the decision to the user.
Hibernate is a tricky thing, because it will only work with external interrupts and basically requires additional custom coding (e.g. like Andy’s project)
thats why I’m a bit reluctant to put such functionality in the default firmware. The hints are there so if some one wants to customize (like Andy did) the pointers are there. Same goes basically with the whole watchdog thing. If one really wants to go this route then it’s imho much more easy to write custom code than trying to create a command structure to capture this behaviour.
There seems to be a bit more life in Firmata again, so I’m waiting for them to come with an updated version which we can run via serial and radio. That would be nice for a 2.0 firmware and might make hibernate and sleep via firmata commands instead of AT commands.
IDLE is indeed a bit of strange beast as TX does basically the same, so yes we could ditch IDLE. @Icing: what do you think about removing IDLE mode ?
I also notice that it is nonsense of IDLE mode, and it’s more compact to keep TRANSMIT_MODE, RECEIVE_MODE, TRANSCEIVE_MODE, LOWPOWER_MODE. And SLEEP_MODE can also be removed as there’s no ATMD5, with ATSL instead.
Glad you had a great vacation. While you were out I spent some time playing with XBees to understand how they deal with these issues. This post will summarize what I have learned.
To configure ports that have a set of AT commands D0-D9 and P0-P3 as well as M0 and M1.
For the D? and P? the values 0-5 that configure the available pins. The values are 0 disable, 1 some form of enable if the pin has a standard use on their boards like an LED or button. 2 analog in if appropriate, 3 digital in, 4 digital out low, and 5 digital out hi.
For sending values they have several other params. IR which is the report interval, ST which is the time until it goes to sleep(WT makes more sense, but I am reporting what I learned.), SP for sleep period, IC which is a BITMAP of which pins are being monitored for change.
SO is for sleep options, 0-6 I can report more on that if you like.
So to monitor a pin you set the pin mode with ATD0n (n=0-5) set the reporting interval ATIRn(n=16bit value in ms units), ATSPn(n=16bit units are 10s of ms) the sleep mode ATSOn(n0-6) and/or ATIR(16bit mask of pins). Then everytime it notices a state change, or IR ms has past while awake, it sends a 2byte hex code of the digital pins with those selected as inputs reported( I believe it skips this if no digital inputs are selected), the rest 0 then a \r and if any analog values are being monitored they are sent one per \ras ascii numbers. If the unit is asleep it sleeps until the sleep pin is manipulated or the time period expires, then it wakes up for ST ms reporting changes vi IC or every IR ms. M0 and M1 let you set the pwm output value of the two pwm ports that they have.
To query values you can use ATIS and it generates the same output. Unfortunately there is no AT command to query a remote node, that can be done via their api, but not via AT that I could find, although I know I once found the command to connect to the AT processor of a remote node, I can not make that work currently.
They have a few more modes dealing with counting syncs of coordinators and missed syncs, but I think this captures most of it. Almost all the pins can be remapped this way. They also have a WH which is a send a character to the localhost to wake it interval. The IR and IC triggered packets are just sent to the output data stream across the radio. To poll with the API you send the remote node an ATIS, and get the output back in response. API mode is a different set of firmware that is designed for uprocs to speak to each other with. Each command in the AT set is sent to and address with variable input data, and a binary packet is sent in response which is sent back to the requesting processor as a packet. Basicly all AT commands are designed for humans, and a packetized version exist for programs. When you configure a node you pick API or AT firmware and load the one you want. There are a few things like polling an IS command that are only in the API, but the rest is in both.
Icing wants to launch a new batch of RFBees with the new V1.1 firmware. Therefore I rounded up the last changes and commited R41 (code.google.com/p/rfbee/source/detail?r=41)
The log message says it all:
I’ll be working now on updating the documentation.
Just tested in my ipod touch (the only Apple at hand ) and the toc does not show a box.
So it must be something special to your version of Apples preview.
I just dowloaded v1.1 and try to compile in Arduino_021
In file included from RFBee_v1_1.cpp:207:
TestIO.h:5:20: error: config.h: File or folder does not exists
RFBee_v1_1.cpp:305:23: error: rfbeeCore.h: File or folder does not exists
I just unpacked all files to my sketchbook folder.
Also tried to comment out all related to TestIO
Doing some additional demos I have found that the device does not recover well from a receive buffer overflow error. I have been poking at it a bit, and I thought I mention it. I also don’t fully understand why I am getting them in that the totalled transmitted is less than the full buffer size.
) I’d rather leave the decision to the user.