[LIM PHANG MOH]

Hi,
I personally have never use this I2C multiplexer chip before. But looking through the code and the library usage, I can’t see anything that could prevent this from working on the V3. The EUI-64 memory chip has a 0x50 I2C address, so that could be rule out. Do you have a more complete code that works on the Pro Mini?

[LIM PHANG MOH]

I tried to upload your simple program to read out the Device-ID with AT-Commands using a terminal program (sys get hweui).
I was not successful to upload it with different boards selected in the arduino-ide (Genuino UNO, TheThings UNO)
I also used differnt FTDI-adapters.

Board should be Arduino Pro Mini ATMega328P 8 MHz 3.3V.

Did you flip the slide switch to RN after uploading the simple code? Also, most FTDI adapter comes with 3.3V that has only 50 mA (ours come with 200 mA). Baud rate should be 57600 bps when communicating directly with the RN2483.

And if you upload the example code posted on our repository, that itself will print out the DEVEUI on startup. You don’t have to deal with the RN2483A.

Could you please enhance your documentation and give us an example to read out the device-id in case all your customers need that for continuing with TTN

Yes, I will complete the documentation by this weekend.

[LIM PHANG MOH]

Yes, you sure can on the regular pin A4 and A5.

[LIM PHANG MOH]

Hi Marc,

I think I know what happen based on a beta tester’s experience while trying to update the firmware. When you tried to update the firmware without uploading that simple sketch in the first place, the D8 and D9 will interfere with the updating process and causes the RN2483 to stuck in DFU mode due to corrupted data.

In order to recover it, once you loaded the simple sketch and flip the switch to “RN”, select “Bootloader Recovery” under the “Module” heading in the LoRaDevUtility, that should help to update the unit’s firmware properly.

by the way, with pin 4 set to HIGH, what are the risks to short the pin with the RN RST button?

Yes, you are right, spot on there. I will probably add a diode to protect in the next revision and will add a note somewhere. Thank you for pointing this out.

[LIM PHANG MOH]

Hi Marc,

My mistake, I didn’t sneak enough on GitHub when I looked at the schematics.
I suspected that the soft serial lib could have issues with high bitrate, but I was somehow puzzled on how to achieve an auto-bitrate when reading the Microchip specs o)

Probably my mistake for not updating the link from the product earlier. Added last week only. I’m very sorry on this.

I will try using your script tonight + provide extra power, but I’m quite pessimistic: I had no issue talking directly with the RN2483 using the serial tool (+ switch in “RN” position) but I couldn’t get any data out of the RN after this silly FW update attempt. This is why I think this is beyond the buggy java interface. I also tried to reset the RN while the tool was probing the serial port, without success.

Without that small sketch I gave, pin D8 and D9 will interfere with the RN2483A UART pins. I’m pretty sure it’s that. The Java program sometimes doesn’t response. At times, I also think I bricked some of the RN2483A, but after a few tries, it work.

[LIM PHANG MOH]

Hi Marc,
Actually, there’s some slight modification to the TTN library example which I have posted here.

All you need is to replace the correct appEui and appKey.

In order to communicate directly to the RN2483. Just load this simple code:

void setup()
{
  pinMode(4, OUTPUT);
  // Pin 2 in connected to the TX of RN2483A used as interrupt during sleep
  pinMode(2, INPUT);
  // Let the internal pull-up on RN2483A does it job 
  pinMode(4, INPUT);
}

void loop()
{
}

Then slide the switch to “RN” position to talk directly to the RN2483A without the MCU. Pin 8 and 9 used for the AltSoftSerial will not interfere with the communication once the above sketch is loaded. This will be more reliable than the code you have posted.

I doubt the RN2883A is bricked yet. Try again with the Java tool and you could press the RN RESET switch as the software is a bit buggy to look for the RN2483A module, it does help.

Also, if powering from the 3.3V FTDI, make sure they are able to supply enough current. Most FTDI adapter out there (other than ours) only provide 50 mA of output current.

We upgraded the RN2483A firmware to 1.0.4 during production and also connected each unit to TTN during testing.

I’m sorry that you came into this issue as the user guide is not up yet. Will complete the remaining portion as soon as possible.
Thanks.

• This reply was modified 6 years, 11 months ago by LIM PHANG MOH.

[LIM PHANG MOH]

Hi,
It’s back in stock few moments ago! Sorry for the wait.

[LIM PHANG MOH]

yes – exactly this example. I’d expect to get a “connected” message on the TTN Console (as I used the DevID and AppId from another board that already worked fine) but nothing happened.

The board has a built-in DEVEUI that it reads and uses them. Unless you hard code them, the code uses this. So, if your backend on TTN is mismatch due to this, then it’s obvious it won’t get registered.

or how can I check that the board is working (I also see no decrease in power consumption, it’s always 0.03A)

Probably it went to sleep hence a lower current (but you are powering by USB hence it’s not uA range although sleeping). Try loading a known simple sketch like blink to get the board detected all the time by the PC again.

If you are ready for sleep mode yet at this stage while testing, you can always comment out the sleeping portion to see whether it works.

[LIM PHANG MOH]

Hi Bernd,

Lora-TTN-Example

Is this the example found here?

If yes, the board went into sleep mode hence it will disappear from your USB COM port list. And double press in quick succession of the reset button would allow you to load program.

[LIM PHANG MOH]

So now I see that the mini pro ultra is out of stock in the RFM95W, 915MHz combination. Is it expect to come back in stock any time soon?

Towards the end of next week. Currently busy building the Mini Ultra LoRaWAN boards. May I know what antenna connector you are looking at?

As I am looking at about 3km of max. reach (but pretty open, non-urban), the RFM69HCW is probably not feasible, but I see the V2, 915MHz is still in stock. So I can either go for that combination and limit my range, or for the v3, RFM95W, 868MHz. As I would do pure Lora at the moment, would it work (I read some conflicting stuff online)? I understand upgrading to LoRaWan will be out of the question then…

The furthest we have went with RFM69HCW is slightly less than 2 km is very open test ground. I wouldn’t put my bet on it to beyond that. You can run the board on pure physical LoRa using RadioHead library and move to LoRaWAN later using the LMIC library.

[LIM PHANG MOH]

Hi,

I am a complete newbie to LoRa or LoRaWan so bear with me :). I am considering to use the Mini Ultra Pro V3. It hits all the right buttons for my project, which involves a monitoring station which is very difficult to access (for months). I’ve got everything except for the radio transmission running based on a Pro Mini. I do not currently have access to a gateway and, at least for prototyping reasons I am considering if I could use two Mini Ultra Pro’s with radio to simply transfer data, i.e. one in the field, logging and transferring the readings, and one on my desk, writing everything to SD. Does this make sense?

You could use the LoRa layer (without the LoRaWAN stack as you do not own a gateway) by running the RadioHead library. The Mini Ultra Pro also has an on-board serial flash which you could use as logging. You can take a look at the code in this post I wrote. You can just use a PC to pull out the data. Do note that the on-board serial flash is only 2 MB (16 Mb) which is not a lot but I believe it is more than adequate in most cases. The SerialFlash library by Paul Stoffregen allows accessing the serial flash like how you would access an SD card on Arduino platform.

BTW I am based in Singapore, not sure if I need to consider anything with regards to working frequency if I do such end-to-end solution.

Singapore runs on 915 MHz band.

• This reply was modified 7 years, 8 months ago by LIM PHANG MOH.
• This reply was modified 7 years, 8 months ago by LIM PHANG MOH.

[LIM PHANG MOH]

Hi Tony,
Unfortunately no extra pins left. We used everything up on the ATtiny1634R MCU.
In the past (in the shield form), we did try to use a fan to cool down it does seem unnecessary as the temperature drops way too fast (to cause thermal shock on component). Until today (9 years using the reflow system), I would usually just open the door and let it cool down by itself naturally which is well within the maximum 6 Degree Celsius per second rate.

[LIM PHANG MOH]

You can take a look at the TPS61240 datasheet on page #6.

[LIM PHANG MOH]

Hi,
It depends on your input power battery voltage. On the product page, it was mentioned you could get up to 450 mA if used with a 4.2V input battery. The lower your input battery voltage, the less the output current is as it needs to boost a larger gap.

[LIM PHANG MOH]

Hi SteveD,

Here’s a skeleton code for your application:

volatile bool pirTrip = false;
loop()
{
  .....
  attachInterrupt(0, pirTripEvent, LOW);
  LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
  if (pirTrip)
  {
    pirTrip = false;
   // Send data, etc
  }
}

void pirTripEvent(void)
{
  pirTrip = true;
}

[Author]

Posts