[Andrew Lindsay]

Thanks Jason, that was what I was hoping. Checking with network provider as they only send the status requests twice a day.

thanks

Andrew

[Andrew Lindsay]

Thanks for the update.

Andrew

[Andrew Lindsay]

I think you might be misunderstanding what LoRa can do. From your description you seem to suggest the xDot is being used as a serial link replacement and can receive and transmit at will. This is not the case.

You would have to buffer data, send it out, receive any response and wait for the next available transmission window before you can send more data.

Andrew

[Andrew Lindsay]

Hi Darrik,

the device is operational again thanks.

Andrew

[Andrew Lindsay]

Seems this issue has already been reported on developer.mbed.org forum with a workaround that seems to work.

https://developer.mbed.org/questions/78300/xDot-ADC-problem-when-coming-out-of-slee/

Thanks

Andrew

[Andrew Lindsay]

If you’ve got the screw connector (SMA-RP) then you just need the antenna to screw on, the Pulse Electronics W1063 is the one that Multitech have been supplying with the Conduit gateways and I’ve used it with those mDots.

Andrew

[Andrew Lindsay]

I’ve used the Molex 105262-0002 antenna for inside enclosures or outside use a pigtail https://www.digikey.co.uk/product-detail/en/digi-international/JF1R6-CR3-4I/JF1R6-CR3-4I-ND/1090366 and https://www.digikey.co.uk/product-detail/en/pulselarsen-antennas/W5012/553-2586-ND/2649130 or https://www.digikey.co.uk/product-detail/en/pulselarsen-antennas/W1063/553-1474-ND/1634416

Andrew

[Andrew Lindsay]

Got a binary image from support but it doesnt give any output so back to where I was – A failed xDot that is now unusable on a custom board that is now scrap.

Andrew

[Andrew Lindsay]

Do you have a utility that allows me to fix this issue that you can share with me?

Thanks

Andrew

[Andrew Lindsay]

Hi Peter,

EEPROM is used, I use the functions within the library to read and write to it. Only around 365 bytes are used to hold device configuration parameters that a used can set via a bluetooth app. These start from address 0 and have been this way for some time before the device decided to erase its device id.

Are there specific locations that hold the device configuration? I’m sure the library would block access to these locations.

Andrew

[Andrew Lindsay]

Hi Peter,

Multitech provided a utility for the mDot that allowed the device ID to be reset after flash corruption. I wasn’t aware the xDots suffer from the same problem.

I’ve raised a support ticket.

thanks

Andrew

[Andrew Lindsay]

Slightly related, is it possible to change a 868MHz xDot to a 915MHz part by running a custom firmware image that updates some internal EEPROM values as I could do with the mDots after the flash had been corrupted?

Reason is that I cannot get hold of 915MHz parts for a US based project and apparently the factory don’t have enough available for another month.

Thanks

Andrew

[Andrew Lindsay]

Hi,
I use a 10K resistor pullup and a 100nF capacitor between NRESET and Ground. If you then add a reset button you then connect it between NRESET and Ground.

Thanks

Andrew

[Andrew Lindsay]

OK, update now. I did a bit of reorganising the way the different parts get initialised and this seems to have fixed it for now.

Cheers

Andrew

[Andrew Lindsay]

Not been able to produce a simple application that demonstrates this. I thought it had gone away but seems to be back. Any tips on debugging this other than removing and adding bits of code to see where it fails?

thanks

Andrew

[Andrew Lindsay]

I was using the last stable libxDot-mbed5 and this had issues so tried the latest libxDot-dev-mbed5 (including your recent fixes today) with the correct release of mbed-os for each.

other libraries include are for DS18B20 and another I2C battery monitor device.

Cheers

Andrew

[Andrew Lindsay]

Thanks Mike, they are in the ChannelPlan.h file now so I’ve still got to make changes to use them.

Andrew

[Andrew Lindsay]

OK, thanks.

[Andrew Lindsay]

I’ve been looking at the changelog and is shows that libmdot-mbed5 2.0.16 has the fix, but the revision details for libmdot-mbed5 show it is only at release 2.0.15:

Revision 57:610f9e955516
mdot-library revision 2.0.15 and mbed-os revision mbed-os-5.1.5

Can you confirm this fix is in the production release or that it is only currently available in the dev version of the library? If only available in the dev library, when is it scheduled to be pushed into the production library?

thanks

Andrew

[Andrew Lindsay]

Thanks Peter, I’ve got it connected fine as I’ve used a regular FTDI cable to test it.

Andrew

[Andrew Lindsay]

Yes, xdot is on the dev board, doing some evaluations before committing to a design. So far the xDot is losing out to other manufacturers. Its latest mbed-os and I also tried the latest mbed 2 but that wont compile for xdot anyway.

Pins on both devices are UART_TX and UART_RX on the xDot. I’ll check the rest and try again later. Not able to look just yet.

Thanks

Andrew

[Andrew Lindsay]

Its the UART1 interface I’m using on the xDot not the USB interface.

[Andrew Lindsay]

The Maxbotix sensors have a number of interfaces, Analog, PWM, Serial or I2C. I’ve successfully used the Maxbotix sensors using the PWM option. The MB7137 uses I2C which will be fairly trivial to interface to the mDot. There are 2 commands, one to tell the sensor to take a reading, the other to retrieve the reading as 2 bytes of data.

Regards

Andrew

[Andrew Lindsay]

Other manufacturers are using the same sort of footpints, I know of one that has the same functionality as the xDot in a package that is 1/4 size at only 12mm x 12mm!

They aren’t designed to be hand soldered. Our design s being finalised ready for prototype production in the next few weeks.

Andrew

[Andrew Lindsay]

Hi Leon,

Thanks for the response. Trying 5.1.4 and I’m able to talk to the devices.

Cheers

Andrew

[Andrew Lindsay]

If you are only using the factory firmware or programming the mDots in a UDK dev board then most xbee based boards should work. As I’ve not tried this myself, I’m only comparing the pinouts.

thanks

Andrew

[Andrew Lindsay]

Thanks,

Are you saying there is currently, when using sleep, no way to determine if it was the RTC or wakeup pin that caused the mDot to come out of sleep mode.

Andrew

[Andrew Lindsay]

It can be frustrating at times….When I get a spare day I may even tackle mbed-os5!!!

Thanks for your continued support Mike and the guys.

Andrew

[Andrew Lindsay]

OK, thanks Mike for this. Documentation is key.

I’ve tested some new code using the Dot examples sleep and I/O configuration, I’m now seeing less than 50uA so an improvement.

Regards

Andrew

[Andrew Lindsay]

I decided to do some tests on this comparing deep sleep libmDot to the sleep only crippled libmDot. There seem to be some interesting results.

libmDot 15:b50f92f when using deep sleep – 75-90uA.
libmDot 17:0da384b+ When using sleep – 130uA.
libmDot 17:0da384b+ When using deep sleep and get warning – 42uA

If selecting deep sleep is producing the warning saying it is using sleep instead of deep sleep, then why does it show a much lower power consumption that when sleep is selected?

The 42uA was not consistent as sometimes when it entered sleep mode via the deep sleep warning it failed to reduce the power consumption at all and stayed above the normal 6mA or more.

I’m going to repeat the tests again in the morning and try a number of mDots to see if this is the same on them all.

Thanks

Andrew

[Author]

Posts