We have made the connections as mentioned on your wiki but we are making no progress. On trying to add node on the multitech gateway using the keys mentioned in the example code , we get a reply connection refused. Unfortunately we dont have much idea of using Linux. Also after uploading the lmic 1.5 code as mentioned on your wiki the Serial port( USB) gets disconnected from the computer and teensy 3.2 is shown as unsupported USB device because of which we cannot see any serial print messages. On your website you have mentioned you have got the MultiTech gateway working. Can you kindly help us , we are developing LoraWan setup for an educational township
I have built the same, but using Teensy LC and HopeRF RFM92W module and I’m still debugging this so not seen anything sensible through it yet but this could partly be down to TTN not displaying all the node values yet.
Hi,
Yes I made the changes in the config file for RFM95. Is there any way I can check the communication from node to node. The code given by TTN is for sending only and probably receiving on a Gateway
Just tried my Teensy LC and HopeRF RFM92W module together as per the wiki details and it is able to connect and send messages via my Multitech Conduit and see the results via the API.
Can confirm the USB disconnect for the RFM95 using a Teensy 3.1. With or without the config.h alterations, and making sure I had a clean build. It is not hardware related (have a few RFM95 modules laying around). The RFM92 works like a charm when I upload the sketch when I use the same layout on the breadboard and only changing the module. Using a RFM92 I can connect to serial and see the message from the device on TTN/MQTT
I could not imagine, that just a teensy 3.1 should have a malfunction in the usb.
we have built several nodes based on Thomas’ code and teensy-lc and teensy 3.2 with hoperf RFM92W & RFM95W. all of them could be debugged via serial.print on the usb.
I also use Termite 3.1 on win10 as an usb-terminal. maybe that works?
Yes, we had the same problem yesterday evening while testing Teensy and HopeRFM95W. Disconnect from USB
We didn’t have a external power supply available but perhaps you could try a seperate power supply for the HopeRFM95W
I have exactly the setup you describe here in front of me, and it works.
One thing to check maybe: is the reset properly connected? This pin is inverted on the RFM95W, and it might explain why that one doesn’t work while the RFM92W does.
@ursm: The devices crashes and renders the device innumerable in the USB chain and thus does not provide a com. Same result in dmesg when I plug it in a Linux machine. @Thomas: Indeed this is strange. I’ve attached the HopeRF specsheets and I do not see any difference. Also no difference in the XBee shields and used the multimeter to be sure. Or do you mean a High/Low inversion on the pin itself?
what’s your developing environment?
on some levels of windows you need to install a virtual com driver
that was not necessary on my win10 environment with arduino 1.6.5 and the teensyduino 1.26
@smeedy
what Thomas means is that it might be that your RFM95 is constantly resetting itself. If you use an RFM95 instead of RFM92 that everywhere in your code where the reset pin is made HIGH it has to be changed to LOW, and everywhere where it’s set LOW, it needs to be changed to HIGH.
I should be shot on the spot. Had some multiple lmic libraries lying around. Turned out I was changing one and compiling another and thus using the SX1272 reset setting while using the 95 as you guys predicted. The RFM95 worked without a problem. On a next meeting, beers will be on me.
Only thing I’m struggling with is formatting nice JSON using and sending it thru the LMIC_setTxData2 method. I’m using the https://github.com/bblanchon/ArduinoJson lib to prepare my message. But when I’m allocating space and printing it to the uint8_t array it looks like the JSON is malformed. I’m suspecting the measurelength() for the JsonObject is not consistent.
So somewhat off topic. Do you guys have a best practice formatting JSON before feeding it into the setTxData? Any pointers will do.
My advice: don’t use json. Air-time is a limited resource, and you don’t want to waste it on sending formatted data. Keep your payload as compact as possible, it will allow you to send more data, and more often.
I actually have a blog post about that combo My IoT blog. Works no problem. Also got couple of RFM95s going with different mBed MMUs. Ping me if you need more details
Wojtek
