When you plan to deploy / sell sigfox based solution to consumer, you have to manage you device park. The sigfox network have a restricted radio medium to ensure you will not emit more than what you payed for you will be charged by them if a device you own is emitting, even if it is emitting out of your control. There is no network subscription like in 3G before being able to emit so anyone can emit. That is why, to ensure every one is clear, you have an extra cost if you emit more than you are allowed or if you emit from a non registered device.
When you are designing end-user system you have no control on the device and if you propose a monthly fee to use your solution you will never sure the end user will unplug it once he stop to pay for your service. It means you could have a consumer stopping to pay for your service but a device continuing to emit and sigfox request you to pay for it.
Since the network allow you to have downlink message, now you have the capability to send order to your device and as a consequence allowing you to kill the device remotely. This is a good solution !
Next you have a new scenario where your end user finally decide to reuse your service and want to reactivate the device. At this step you won’t be able to communicate with it and you will have to find another way to reset its state to normal. You can eventually add a “factory reset” button or request to reflash it. There is another funny when : playing with the reboot time.
This post will describe how to lock a device to stop emit on network and how to play with the startup sequence to reset it. Read more !
After some discussions this afternoon with TD support and get a good advice from them, this post details some notice about TD_USER_Loop working way and power saving.
For those like experienced with Arduino, Telecom Design loop is not working like
But it is called on Interrupt ; I don’t know why but I was expecting it to be called every tick (32KHz) which was a wrong assumption. In fact, this procedure is called on wake up from any interrupt. The frequency of call can’t be determined, it can be not called in a minute if no events occurs. That is why schedulers helps you to have a predictable call.
I just finished a program started a couple of month ago. When I stared to it, I had a hard work to find how to sample a group of 256 values at 32Khz with the EFM32 device embedded in the Telecom Design TD1204 / TD1208 used for my SigFox project. This post details how to do this task
TD1208, SigFox chips, include a RF LAN fonction, this allow you to communicate between different TD1208 chip, locally, without using the SigFox network. This is really interesting if you have a network of sensor, you can connect them this way to a gateway. This gateway will then transmit the information to the SigFox network to reach your IoT service.
This post will describe how the rf_lan work and how to implement it.
I’m not fully sure I implement it the right way as the given example are really poor, the documentation is a mess and the source code of this part is not accessible… More over, my feeling is that this part of the SDK is still running bugs. What I mean is that in a future post you should find an update and a better way to do it than the one I’m going to describe. By-the-way, what is here is working, have fun with it !
You may had some problem to reflash your TD1208 once you load the blink example or your own code in the device. This is because you need to reset the device to reach the firmware upgrade procedure during boot procedure.
On of the way to do it is to perform a hard reset putting Reset pin to ground during TDLoader Sync process. The other way is to add some lines in your code to create a soft reset. Here is an example on howto do it :
When the loader is waiting for the bootloader sequence, it send communication over the serial line. In this example, when a such communication is detected, the system is calling a soft reset, starting the boot sequence and as a consequence the firmware upgrade automatically.