I used the sample Stalker (Stlker_logger_AM06_Serial) together with some other sample that uses the XBee to transmit data.
As soon as I run the combined code, the Stalker doesn’t even follow the trace prints in setup() function and reboots on every loop. Very strange behaviour.
The code in the attached is a bit modified version of the original sample plus some interface with BMP085 and DHT22 that I want in my remote weather sensor. Removing this code did not change anything by the way. In the loop() function if I comment out the XBee send call (//SendOnXBee() all works well (except no XBee communication ).
Any idea why this might happen? Anyone came across something like that?
I have just checked briefly your coding and I have a question: HOW is your XBee powered ?? Do you use digital pin D5 in combination with POWER_XBee jumper on PCB back side for switching on/off the power ??
There is “pinMode(5, OUTPUT);//Bee power control pin” in your setup(), but there is no digitalWrite(5,…) to set D5 HIGH (or LOW) …
If there is POWER_XBee jumper applied than theoretically your XBee is not powered. If you don’t switch XBee on/off now than we have to check the code more.
FYI I use Stalker with BMP085 and XBee Series2 without jumper POWER_XBee applied. I tried to switch XBee on/off by pin D5 but in that case I couldn’t pass the setup() too getting continous board reset (see my topic here in forum) …
HOW is your XBee powered ?? Do you use digital pin D5 in combination with POWER_XBee jumper on PCB back side for switching on/off the power ??
I use the default from factory (and verified thin layer connects EN to VCC). On the VCC side and EN I get 3.0 Volts when reading with a multi-meter.
There is “pinMode(5, OUTPUT);//Bee power control pin” in your setup(), but there is no digitalWrite(5,…) to set D5 HIGH (or LOW) …
That’s a left over from the sample code.
If there is POWER_XBee jumper applied than theoretically your XBee is not powered. If you don’t switch XBee on/off now than we have to check the code more.
Would appreciate. I somehow suspect it has to do with firmware on the board or something.
in the meantime, please take a look to this forum: viewtopic.php?f=4&t=2207 - I placed there my code which works on Stalker with XBee. I don’t read the BMP085 data via library as you but I think is quite clear. I read temperature, accu voltage and charging status and all values are sent via XBee transmission to another XBee.
Thanks a lot Vladimir.
After few more hours of playing with one code base and another I found the source of the problem and it is the SD or FAT code. Originally I wanted to use the SD as backup if transmission fails but I can easily give that up, at least for now.
All seems to work fine so far, except after the transmission (Xbee.send()) I am getting to the code that “should not happen”:
if ( xbee.readPacket(500) )
...
else
{
// local XBee did not provide a timely TX Status Response -- should not happen
FlashLed(2, 200);
}.
Basically readPacket returns 0. Right now I do not have the code on the recieving end as I want it to actually be the PC (and could not find descent C# library for XBee or well documented C++ library for Windows). A terminal based work with XBee Explorer shows binary data getting through and all. Is the “response” made by application on the other side? If that is the case then the “should not happen” can certainly happen.
I plan to store all the records (eventually once an hour sample from multiple points) in a database for future reporting and graphs.
it is fine that you have proceeded little bit further. Please note that I had also problem quite often with “2 LED’s blinks” and I found out the problem are concrete walls reducing the XBee range. Now I have one “spare” XBee in the middle way plugged into XBee explorer which works as the router and everything seems to be OK. So I would like to say only that even yours XBees are logged together and the distance between both more or less comply with technical specification there can be the local messing having influence on transmission. Nevermind I think (99,9% sure) the “expecting” response is done by application running on receiving side.
all works well (except no XBee communication