Verified - fixed /4 changed to /16 in LMIC_disableChannel() for CFG_us915 and now it works, only sends on my single channel gateway frequency of 913.7:
Tested the shield and works ok. Made it available on Oshpark. Shield can be used with ESP dev board. Needs two 8pin single row headers (not the ones on the picture;) 8pin headers and a 10K resistor.
Hi guys,
I see some reference to my github here, I’m glad of your intereset
For those interested I also done a WeMos ESP8266 shield for Microchip LoraWan RN2483 and WiFi terminal to talk to RN2483
You’ll find information here;
github board shield : https://github.com/hallard/WeMos-RN2483
github firmware Serial/Proxy with websocket en HTML Terminal https://github.com/hallard/WebSocketToSerial
cswiger: Interested in your use of the inAir9b and WeMos D1. I have almost the same hardware but I can’t get it to work properly. The setup won’t boot up with CS connected to SS (GPIO15) on WeMos D1 R2 board. I can get it to boot up with inAir9b unplugged, When it is booted up the plug the inAri9b in and with works.
If I have CS connected to inAir9b then is doesn’t start at all, doesn’t matter what GPIO0&2 are doing.
Did you get this working with your WeMos D1 mini?
Can’t get even the simple Blinky program to work with the inAir9b plugged in with GPIO15 connected.
Anyone got an idea what the problem might be?
There’s an unlabeled pin on the InAir9B between VS and SI that I have connected to 3v3, although it’s labeled ‘5v’ on their schematic, Modtronix says use only 3v3
I have the 5v pin on the WeMos through an LM3671 to provide 3v3 for the InAir9B.
Pin mapping from the sketch - pins.dio can be confusing:
// Pin mapping
// XXX We have to see whether all these pins are really used
// if not, we can use them for real sensor work.
lmic_pinmap pins = {
.nss = 15, // Make D8/GPIO15, is nSS on ESP8266
.rxtx = 2, // D4/GPIO2. For placeholder only,
// Do not connected on RFM92/RFM95
.rst = 0, // Make D0/GPIO16, Needed on RFM92/RFM95? (probably not)
.dio = {5, 4, 3}, // Specify pin numbers for DIO0, 1, 2
// D1/GPIO5,D2/GPIO4,D3/GPIO3 are usable pins on ESP8266
// NOTE: D3 not really usable when UART not connected
// As it is used during bootup and will probably not boot.
// Leave D3 Pin unconnected for sensor to work
};
Thanks for the contributions from you all. Arjan was correct the WeMos D1 R2 does have a pulldown on GPIO15. The extra clue from cswiger made the difference. I connected the pin between VS and SI to 3.3V and it booted after a delay of 10 seconds every time. I added another 10k pulldown in parallel and it the booted properly every time.
The Modtronix documentation around VS is confusing. Their circuit diagram is helpful to work out what the un-named pin is doing.
Thanks for the assistance. I’m still not able to send any messages to Kotahi.net (my local Lorawan gateway). The same inAir9b works fine on my Arduino Mega, so there is something else strange about the setup. Maybe I’ll provide separate 3.3V like cswiger.
Hi, I’ve managed to make a gateway using the LinkLab LoRa gateway. I have the ESP8266 running LMIC and sending packets to the gateway. I can see them at the gateway level or with netcat on the 1680 port.
My question is how about the down link to ESP8266. Did you managed to make it work ? I’ve tried the sudo ./util_tx_test -n 1680 -m LORA -s 7 -t 1000 -z 55 -x 10 to send 10 packets, but I don’t receive them at the ESP level. Having only one way is not LoRa compatible. I know that LMIC suppose to work in the RX2 window. On my gateway I am running (evaluating ) the https://github.com/mirakonta/Raspberry-PI-Link-Labs-LoRaWAN-Gateway sw. The TTN’s version will be for desert
So the question is how to send downlink packets to the nodes ?
(And of course, the gateway must support downlinks too; most Single Channel test gateways don’t. As an aside, beware that downlinks will be very limited, one day.)
Yes, I have a true gateway ( a LinkLab Pi hat ) I moved from single channel gateway ( PI + ESP8266) to a truly gateway and I am aware of the air time ( 10 msg per day downlink is more then enough for me).
I’ve checked the lorabase.h so DR_DNW2 is set to DR_SF9
enum { DR_DNW2 = DR_SF9 };
and the LMIC.dn2Dr = DR_DNW2; in lmic.cpp in function lmicJustJoined. So, I guess I good with that.
Using
./util_tx_test -n 1680 -m LORA -s 7 -t 1000 -z 55
is just enough to have a packet received in ESP ? I’ve seen the packets in gateway but not on ESP, no event EV_RXCOMPLETE is triggered.