I ordered 2 Electron kit from Official store (U260 - AUS/US version). I also purchased a U270 Europe version from my local online store. I am in Australia and we have 3 major carrier - Telstra (U260), Optus and Vodafone (U270 freq). The later two are offering much cheaper data but with limited coverage outside metro area. I used my own SIM to activate and claim the kit as I get greater flexibility and more data every month on those IoT devices.
The first few days I was really impressed with those little kit and it seemed there was no obvious issues while keep it running for days.
However, after I disconnected the power (USB+Battery) from one of the unit, my nightmare began.
Both of the unit have a very high (nearly 100% on my own code - just to flashing the D7 LED) possibility to stuck in bootloop (as far as I believe). It powers itself up but ends up with flashing GREEN, goes WHITE for seconds, then repeat.
Luckily, I figured out to issue the original command during activation stage to bring the device back to work, but I have to say this it not funâŚ
particle flash --serial firmware.bin
I kept those firmware file I downloaded for each of the device.
There is not a lot of info we could go on about what might cause this.
Apart from the known but not yet solved issue with âbrown-outâ conditions and some occasional disconnets due to SIM contact issues on ~1% of devices (blinking blue) the stability is rather good in my experience.
Just a hint
particle flash --usb firmware.bin
is much more reliable when it comes to actually telling you whether a flash succeeded or not.
But as said, we need more info.
How do you exactly power the devices?
Even if itâs simple, how exactly does your code look?
Have you considered SYSTEM_THREAD(ENABLED) and/or a non-AUTOMATIC SYSTEM_MODE()?
I am actually using a modified code from the blinking LED program. I put a few more lines to change the duration between the blinking and upload a counter every 2 minutes.
I am powering the device using the USB port and the battery. During the test, I usually unplug the USB cable and then disconnect the battery connector - this will cut down the power completely.
I would think the âbrown-outâ conditions might be the same issue.
I was thinking the device was faulty but I can replicate the issue by using the different modelâŚ
In regard to the SIM connectivity issues, I didnât get any SIM related blue-light issues from my observations. Also, I am using a 3rd party long life Telstra SIM so I could even eliminate this scenario by calling the number I am currently using on that IoT device.
I must say I cannot afford reprogramming the unit every time my clients get a power failure - I really, really wish this problem can be solved in the near future.
I will definitely have a little bit read for the 2 modes you mentioned above and give it a shot. I am doing this in my spare time so I will keep you updated.
This is the code I am using:
int led1 = D0; // Instead of writing D0 over and over again, we'll write led1
unsigned char countdown = 255;
unsigned int count=0;
int led2 = D7; // Instead of writing D7 over and over again, we'll write led2
void setup() {
pinMode(led1, OUTPUT);
pinMode(led2, OUTPUT);
}
void loop() {
digitalWrite(led1, HIGH);
digitalWrite(led2, HIGH);
countdown--;
delay(countdown);
digitalWrite(led1, LOW);
digitalWrite(led2, LOW);
delay(countdown);
if (countdown==0){
count++;
upload();
}
}
void upload() {
if (count%2==0)
Particle.publish("Count",String(count),60,PRIVATE);
}
Itâs kind of the strange issue to me. The config stays if I donât put any programs on - will a user program erase the APN settings in-built with firmware.bin?
I think I also like the idea to include SYSTEM_THREAD(ENABLED) option so my code would run soon after it powers up.
One more question, would it be possible to read / retrieve ICCID information from the user program? Letâs say I am using 2 carriers for my projects and it would be great if I can write few more lines to do auto setup based on ICCID (first few digits would do I believe)?
Yes, any new firmware will overwrite the previous firmware.
The reason why the setting persists a firmware update is that the APN is written by the code into the cellular modem module and a mere reset does not power down the modem, hence the setting persists. But once you de-power the modem that setting will be gone and your code has to ensure that the modem gets "programmed" correctly again.
Yes that is possible via the respective AT commands of the modem and Cellular.command()
I just don't know the exact command off the top of my head.