Ok so you’re trying to use the ‘cmd’ sample application.
I think the join command there is lora join ( and lora send YourString to send data )
But why don’t you try your own smartbasic script? The cmd app is really an example, not how you usually interface with the module.
Oh f#@k! I did it so many times…
Attempting to join the LoRa network
Tx Done
Successfully joined the LoRa network
THANKS!!!
lora send "jmarcelino"
OK
Tx Done
No Sync pulse
LoRa TX Complete Event
No Sync pulse
On the Raspberry + iC880 gateway:
Apr 14 20:16:54 ttn-it-ge1 ttn-gateway[749]: INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 45 ms
Apr 14 20:16:57 ttn-it-ge1 ttn-gateway[749]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 49 ms
Apr 14 20:17:01 ttn-it-ge1 CRON[837]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Apr 14 20:17:02 ttn-it-ge1 ttn-gateway[749]: INFO: [#260121DB] uUP CRC:OK Freq:867.90MHz ch:7 RFch:0 LORA[SF12 125Khz 4/5] RSSI:-31dB SNR:+7.5dB Size:25b Data:'QNshASaAAQAApWc5rgPFe3SnRpBDKDtAFw=='
Apr 14 20:17:02 ttn-it-ge1 ttn-gateway[749]: INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 45 ms
Apr 14 20:17:07 ttn-it-ge1 ttn-gateway[749]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 48 ms
Apr 14 20:17:17 ttn-it-ge1 ttn-gateway[749]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 48 ms
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: ### [UPSTREAM] ###
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # RF packets received by concentrator: 0
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # RF packets forwarded: 0 (0 bytes)
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # PUSH_DATA datagrams sent: 1 (230 bytes)
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # PUSH_DATA acknowledged: 100.00%
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: ### [DOWNSTREAM] ###
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # PULL_DATA sent: 3 (100.00% acknowledged)
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # RF packets sent to concentrator: 0 (0 bytes)
Apr 14 20:17:54 ttn-it-ge1 ttn-gateway[749]: # TX errors: 0
The TTN console never sees my gateway, but that's another story.
Thanks againGreat! By the way the “No Sync pulse” is perfectly normal, nothing to be worried.
Yesterday I left everything as it was, turned off the gateway with sudo shutdown and turned off my PC and thus the Laird Devel. Kit, powered by USB.
This morning the node doesn’t connect to the gateway. The keys you made me set are still there, but it doesn’t join the network anymore.
lora join
Tx Done
No Sync pulse
No Sync pulse
forever
This is the very first node I connect to the gateway, that’s why I’m using cmd. Once I will see a packet on the TTN server I will start to mess around with code. And the gateway says that it fails to start the concentrator, whatever that may mean.
I chose Laird just because it was the only one that I could buy in few days. I’m on a project scheduled for September that has been changed to May 2nd because a new competitor has a ready-made solution (based on GSM/GPRS).
So I’m afraid I will have to give up. Yesterday I also received some RN2483. Should I try with those?
I have already designed the PCBs for the RM-186 and the RN2484 (+ATmega32U4) and have an Arduino Leonardo, so, for me, one or the other is the same. Well, apart from my 10+ years experience with AVRs.
Are those OTAA keys? Or are you using ABP (in which case the node does not really “join” the network, but has already joined be generating the ABP keys in TTN Console).
And do the gateway logs still show the packet?
That means the gateway is not working. As a result the node can not reach the network.
I suggest you power cycle the gateway, hopefully it will restart correctly afterwards.
BTW. nodes do not connect to a gateway. That is WiFi. Nodes transmit and any gateway that receives the transmission will forward the data to a back-end. All TTN connected gateways will forward it to the TTN back-end where it will become available for you application.
I was referring to the AppEui, DevEui and AppKey.
The activation is OTA.
The log looks very different from yesterday,
It still says
ERROR: [main] failed to start the concentrator,
but it gets restarted every 6 seconds.
The only other error messages are:
ttn-gateway.service: main process exited, code=exited, status=1/FAILURE
Unit ttn-gateway.service entered failed state.
Thanks, kersing, I had already sudo shutdown the gateway twice.
I have a copy of the Raspberry SD right before running the installation script, I will start from that. Any suggestion/warning?
The error you have suggests the iC880a is not being reset properly. Is the reset script setup to use the correct pin for the hardware setup you are using?
Are you using a PCB to connect the iC880a to the RPi or have you wired the setup? In the latter case, are all wires still connected correctly?
I’m using the backplane made by Gonzalo.
The only problem is that, when I substituted my perfectly working jumpers (Gonzalo’s parcel took a couple of days less than yours) I plugged the raspberry the wrong way. I’m about to try to use a undamaged Raspberry and a brand new iC880.
BTW Gonzalo told me that he did the same, without any damage.
Is the reset script configured to use pin 22?
It’s exactly what I’m doing now. Your previous mention made me remember that I followed Frank Beck’s instructions, an his backplane has LEDs. Right now I’m installing the software using Gonzalo’s instructions.
And it works with the same hardware!!!
Only problem is the CRC fail, and no sync pulse
No sync pulse isn’t a problem, just means there was no response on a particular Rx window.
CRC errors also happen all the time.
What matters is if the data arrives at TTN or not.
No, it does not. One message had the correct CRC, but I cannot find any trace of it on the console. The gateway is still not connected, I was going to investigate that.
But if the CRC is correct for just one of 20 messages I sent from the same room, how is it going to work on the field?
With regards to CRC errors, make sure not to place the devices too close together. At least 2m distance is required to make sure you are not introducing issues because of too strong signals.
Ignore that for now as there is a known issue regarding this. Just check for data in the application part of the console. Be aware the console only shows data for a device/gateway when open at the right page the moment the data is received. It does not store data to look at later on.