Post a new topicPost a reply Page 1 of 1   [ 7 posts ]
Author Message
 Post subject: Accelerometer interrupt failure!
PostPosted: Wed Mar 21, 2012 6:42 pm 

Joined: Fri Nov 25, 2011 2:28 pm
Posts: 62
Hello again,

I've encountered a unusual error with some (ideally) straightforward accelerometer operations.

I've uploaded the "WaspAcc_3_FreeFall" sketch from the examples onto two of my motes and have noticed some unusual behaviour.

They will not interrupt when moved to greater than threshold accelerations.
I can observe this by comparing the printAcc() results in serial monitor -

an example:
Quote:
---------------------------------
OX OY OZ
ACC 45 101 1841
Ths: 1024 1024 1024



This means (as i understand from browsing the source code) :

The loop: wait 2 seconds, check intFlag, call printAcc.

All of these appear to work, however the if(intFlag & ACC_INT) is never true - indicating the interrupt is not occurring - even if printAcc() shows accelerometer values that ought to do so.

I'd really appreciate some advice on how to diagnose this issue - specifically how to check the ACC.setFF() beyond checking the return value of 'flag' - in my tests always 0.

It is crucial for me to know the Accelerometer will reliably interrupt the mote when it should.

Thanks a bunch.

P.S. I have tried the direction change example and have similar lack of interruptions.
I have had the expected interruption behaviour from the FreeFall example as well as my own adaptations for some time, so I can recognise when it works... I've updated to API v0.23 recently, but the old sketches worked just fine until very recently.


Top
 Profile  
 
 Post subject: Re: Accelerometer interrupt failure!
PostPosted: Wed Mar 21, 2012 7:29 pm 

Joined: Fri Nov 25, 2011 2:28 pm
Posts: 62
It gets stranger...


I uploaded a piece of ZigBee specific code, using a FF interrupt to trigger sending a packet:

Quote:

#define NodeID "E001"

#define MAX_JOIN_CHECKS 40

packetXBee* paq_sent; 
int8_t state=0; 
long previous=0;
char command[] = ",,,,";
char message[] = ",,,,";
//char messageType = 'N';
char* macHigh=" ";
char* macLow=" ";
int aux_1 = 0;
int aux_2 = 0;

uint8_t timeout = 0;

//char*  data="<<<C:";

//0013A2004068E061
uint8_t macB[8]={0x00,0x13,0xA2,0x00,0x40,0x68,0xE0,0x61};

void setup(){

  RTC.ON();
  
  ACC.ON();
  
  // Inits the XBee XSC library
  xbeeZB.init(ZIGBEE,FREQ2_4G,NORMAL);
 
  // Powers XBee
  xbeeZB.ON();
  
  
  xbeeZB.setJoinNotification(1);
  
  ACC.setFF();
  
  xbeeZB.setSleepMode(1);
  
  RTC.setTime("12:02:20:02:16:00:00");
  
  RTC.getTime();
  
  //RTC.setAlarm2("29:11:00",RTC_ABSOLUTE,RTC_ALM2_MODE4); // Hours and minutes match
  //RTC.setAlarm2("29:11:02",RTC_ABSOLUTE,RTC_ALM2_MODE3); // minutes match
  //RTC.setAlarm1(29,11,0,0,RTC_ABSOLUTE,RTC_ALM1_MODE5); // Sets Alarm1 (seconds matching)
  
  for(uint8_t i = 0;i<5;i++){
       Utils.blinkLEDs(125);
  }

}

void loop(){
  Utils.blinkLEDs(500);

  XBee.setMode(XBEE_OFF);
  XBee.close();
  
  //PWR.sleep( UART0_OFF | UART1_OFF | BAT_OFF);
  
  if( intFlag & ACC_INT )
  {   
      for(uint8_t i = 0;i<3;i++){
        Utils.blinkLEDs(50);
      }
      intFlag &= ~(ACC_INT);  //reset flag
      //sprintf(command,"ALARM,%d,%d,%d,%u,%u,%s>>>",ACC.getX(),ACC.getY(),ACC.getZ(),RTC.getTemperature(),PWR.getBatteryLevel(),RTC.getTime());
      //auxFunction();
      //USB.begin();
      
     // USB.println("Message: ");
     // USB.println(message);
     // messageType = 'A';
      assembleMessage();

    // USB.println("Message: ");
     // USB.println(message);
      
      sendAuxPacket(message);
      //sendAuxPacket(command);
      
      //USB.println("Message: ");
      //USB.println(message);
     
      resetMessage();
      
      ACC.setFF();
  }
  
  //if(intFlag & RTC_INT )
 // {
  // intFlag &= ~(RTC_INT); //clear flag
 /// sprintf(command,"%s%d,%d,%d,%u,%u,%s>>>",data,ACC.getX(),ACC.getY(),ACC.getZ(),RTC.getTemperature(),PWR.getBatteryLevel(),RTC.getTime());
 // auxFunction();
 // sendAuxPacket(command);
      //USB.print("Message: ");
      //USB.println(command);
 // }
  
  //delay(5000);
}


void sendAuxPacket(char *){
  XBee.setMode(XBEE_ON);
  XBee.begin(9600);
    // Inits the XBee XSC library
  xbeeZB.init(ZIGBEE,FREQ2_4G,NORMAL);
 
 // Powers XBee
  xbeeZB.ON();
  
  xbeeZB.getAssociationIndication();
  while((xbeeZB.associationIndication)&&(timeout<MAX_JOIN_CHECKS)) //while not connected...
  {
      Utils.blinkLEDs(1000);
      xbeeZB.getAssociationIndication();
      timeout++;
      
  }
  timeout=0;
  if(!xbeeZB.associationIndication)
  {
        paq_sent=(packetXBee*) calloc(1,sizeof(packetXBee)); 
        paq_sent->mode=UNICAST; 
        paq_sent->MY_known=0; 
        paq_sent->packetID=0x52; 
        paq_sent->opt=0; 
        xbeeZB.hops=0; 
        xbeeZB.setOriginParams(paq_sent,MAC_TYPE); 
        xbeeZB.setDestinationParams(paq_sent, macB, message, MAC_TYPE, DATA_ABSOLUTE);
        xbeeZB.sendXBee(paq_sent); 
        
        
        if( !xbeeZB.error_TX )
        { 
            for(uint8_t i = 0;i<5;i++){
                 Utils.blinkLEDs(125);
            }
        } 
          
        else
        { 
           Utils.blinkLEDs(100); 
        }
  
        
        free(paq_sent);
        paq_sent = NULL;
  
  }
  

}

void auxFunction() //write to string function
{
  sprintf(command, "%s", command);
}

void assembleMessage(){
  //message[0] = messageType;
  message[0] = NodeID[0];
  message[1] = NodeID[1];
  message[2] = NodeID[2];
  message[3] = NodeID[3];
  

  USB.print("message fn check");
  USB.println(message);
}

void resetMessage(){
  for(uint8_t i=0;i<4;i++){
    message[i] = ',';
  }
}



I can't pinpoint why it started working, but the interrupt occurred with this sketch (observed LED's and Xbee line via USB & serial monitor) and the FreeFall example breifly interrupted as normal for approximately 2 - 5 minutes. after this time it would not interrupt. under the assumption the ZB sketch above 'fixed' the issue I uploaded it to both motes, then tested for interrupts - one of the units interrupted when tested the second did not. when I reset the mote manually it began behaving normally.
I should mention I recompiled, reuploaded and tested both the example and other previously working FF sketches onto two waspmotes with no interruptions under interrupt accelerations Before I tried the above sketch. I cannot rule out my JRE or winXP OS being causes of error but it seems unlikely if the IDE/serial monitor works fine. I am using IDE v0.2


Thanks again. (sorry for the length of the description)


Top
 Profile  
 
 Post subject: Re: Accelerometer interrupt failure!
PostPosted: Thu Mar 22, 2012 12:55 pm 

Joined: Fri Nov 25, 2011 2:28 pm
Posts: 62
Hi again,

Quick update:

I've been using winXP to run the IDE, however to eliminate this possible source of instability
I retried the "WaspACC_3_FreeFall" example on Ubuntu, same issue with lack of interrupts under conditions I've observed in the past to reliably generate them.

I think I can eliminate OS / IDE error - given I've used both IDE v0.1 & v0.2 on both OS's.

Thanks.


Top
 Profile  
 
 Post subject: Re: Accelerometer interrupt failure!
PostPosted: Tue Mar 27, 2012 12:47 pm 

Joined: Mon Sep 28, 2009 1:06 pm
Posts: 7501
Hi LiamatTitan,

We have been testing again he free fall example here in Libelium and didn't find any problem with the interruptions. Did you add any modifications in yours? Also, do you have anything connected to the mote, apart from the battery or the XBee module? Anyway, can you repeat your tests with the free fall code provided in the development section of the Libelium's website and only the mote connected to the USB port?

If the problem persists, it should be owed to a hardware issue and we will have to start an RMA process.

Regards.


Top
 Profile  
 
 Post subject: Re: Accelerometer interrupt failure!
PostPosted: Tue Mar 27, 2012 6:32 pm 

Joined: Fri Nov 25, 2011 2:28 pm
Posts: 62
Thanks for the help,

On all of these tests i've removed all but the batteries from the motes - when uploading & running these tests.

I've taken the code from the Development section of the site (as far as I can see it's exactly the same as the 'examples' code that comes with the IDE)

I uploaded it to three motes, the first two were the motes I'd previously had 'bad' behaviour - lack of interrupts - from. The new code did not change the behaviour.

The third mote I tested on responded as normal - this is an indication to me that the issue could be mote specific, i.e. a hardware issue on the 2 motes.

I appreciate your time on this.


Top
 Profile  
 
 Post subject: Re: Accelerometer interrupt failure!
PostPosted: Tue Apr 03, 2012 12:06 pm 

Joined: Fri Nov 25, 2011 2:28 pm
Posts: 62
Hello again,

I seem to have found a solution to my interrupt (& GPRS) difficulties.

I've been testing using the standard (i.e. example) code, following the standard procedure http://www.libelium.com/forum/viewtopic.php?f=16&t=7702 and had inconsistencies.

A colleague who is helping the troubleshooting brought this to my attention:http://www.libelium.com/forum/viewtopic.php?f=14&t=1972&p=5544&hilit=sniffer#p5544

I have to admit some confusion at what seems a contradiction
Quote:
4. Make sure the auxiliar battery is connected and has charge.

VS.
Quote:
You have to remove the coin cell to upload a new program and avoid problems with GPRS or interruptions.


I am not complaining however. I've tried the latter advice, and have excellent, responsive and configurable behaviour on all motes w.r.t. Accelerometer & GPRS association for my two test GSM networks.

I think this issue has been solved, It's great the motes work, but if I could clarification
on why this is it would be ideal.

Thanks for your help.


Top
 Profile  
 
 Post subject: Re: Accelerometer interrupt failure!
PostPosted: Wed Apr 04, 2012 10:00 am 

Joined: Mon Sep 28, 2009 1:06 pm
Posts: 7501
hi Liamattitan,

it is a strange problem that happens very rarely that we hadn't seen for a very long time, the coin cell powers the RTC during programming without control of the microcontroller, which may take it to a state in which it interferes communication with the GPRS or accelerometer (they all share interruption and UART lines).

As I said, it is a very weird trouble that hadn't happened for a very long time, I am very sorry we missed it.

Regards.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post a new topicPost a reply Page 1 of 1   [ 7 posts ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Libelium theme based on 610nm Style by Daniel St. Jules of http://www.gamexe.net


© Libelium Comunicaciones Distribuidas S.L. | Terms of use