I am starting LoRaWan (ABP) simulation on https://simulator.mbed.com/ and I have a problem that TTN is not receiving messages from Mbed Simulator. How can I fix it?
The Serial output shows that the message has been sent, but at the TTN console, there is no incoming message
Can anyone tell me where I went wrong and what is the way to solve this problem? I’m a new member and I’ve lost a lot of time on this issue. Thank you!
As a public network, TTN is not for use with simulators which are inherently private, but only actual nodes reporting through actual public gateways. This has been the consistent conclusion every one of the many times “faking” traffic has come up on the forum in the past.
If you want simulation you’ll need to run your own server stack.
If MBED intends to offer traffic simulation (very unclear that they do), they’ll need to not only simulate the gateway (and not just the node) but also provide their own non-TTN server infrastructure.
Generally it makes little sense to simulate a LoRaWAN node, given that its hard to do a meaningful simulation of sensors. The appropriate testing would involve actual hardware, potentially even automatic CI type testing. Otherwise things like packet packing can be given unit tests independent of the sensor input and radio stack.
And it’s often useful to make your node firmware give a serial debug printout of the packed application packet before it is delivered to the LoRaWAN stack for encapsulation in the protocol wrapper and encryption.
Not withstanding the comments from @cslorabox regarding the pitfalls of simulating LoRaWAN, the Mbed simulator has had a LoRaWAN (ABP & OTAA) example that does in fact feed data by some magic through to the v2 EU gateway for some time. And you do have to write proper code that is run by the Mbed LoRaWAN stack so it does things ‘properly’ for whatever values of properly the code base is working to.
However it was never meant to attract the attention of so many university courses using it as a non-hardware course component with the consequential server load. It would be a work of genius if anyone cared to resource it properly, but it doesn’t appear so, resulting in generally not loading the WASM after you’ve clicked the run button & its compiled your code - so it either shows an error or just sits there throwing random JavaScript errors in the background.
FWIW, my previous fiddling from a year back worked once just now and then just devolved in to random different errors.
In terms of learning, you could do everything you want to do with the simulator on a non-LoRaWAN project and just have it dump the payload to the console rather than send. The actual mechanics of transmitting a payload are very much in Black-Box territory (not the plane sort, which as we all know are in fact Orange). So if you have a piece of hardware with a working LoRaWAN stack, you can then develop the sensor reading & payload construction in isolation and then bring them together at the end.
PS, please don’t tell @cslorabox that the demo sends text, just know that we don’t do that sort of badness around these parts.