Leon Lindenfelser
Forum Replies Created
-
AuthorPosts
-
Leon Lindenfelser
ModeratorModeratorHi Evangelos,
Sorry but the VBAT pin is not externally available on the mDot. It is tied directly to VDD.
Kind regards,
LeonMarch 20, 2017 at 10:00 am in reply to: mtxdot XDOT-NA1-A00 MODULE SERIAL MODE(peer to peer ) DATA MISSING #17891ModeratorHi Son,
You can escape from serial data mode by sending +++. From there you can issue AT commands to reset it to factory defaults… AT&F, AT&W.
Kind regards,
LeonModeratorHi Tae,
You do not need a shield.
In the pdf found at the following link, see chapters 9-12 for the MTUKD2 and chapter 13 for the MTMDK.
http://www.multitech.com/documents/publications/manuals/s000612.pdfMTMDK
http://www.multitech.com/models/94558020LF
MTUDK2
http://www.multitech.com/models/94558010LFKind regards,
LeonModeratorHi Mark,
That is safe to do. The buffer chips U12, U13, U16 & U17 are what connect to the xDot from the developer card. If they are not powered, they should not draw current. If you are uneasy about that, you can power the developer card with JP5 installed then power the xDot. Either way, configure the xDot IO that connect to U12, U13, U16 & U17 as analog no pull to obtain least power draw. Also pay attention to GPIO0 as it connects to an LED. Again analog no pull would be least power.
Kind regards,
LeonModeratorHi Ajay,
One other thing to keep in mind as you are testing… With the mDot and Conduit in close proximity, the signal may be too large for the receivers causing signal degradation. If they are a couple feet away, you can remove one or both antennas.
Kind regards,
LeonModeratorHi Ajay,
NodeRED has an analog GPIO input node that you can use to read analog voltages using the MTAC-GPIO card. So your idea should work just fine. Below is a link to information about the GPIO card. Of course you can also pull the analog GPIO input node into a flow and read the detailed information about it. You’ll see that the input range it 0-5v. So you’d need a voltage divider if your input voltage is higher than 5v.
http://www.multitech.net/developer/products/accessory-cards/mtac-gpio/Kind regards,
LeonModeratorHi Ajay,
There is nothing built into the Conduit that will allow you to determine the current draw through software. Here are some power draw numbers from our side.
http://www.multitech.net/developer/products/conduit/mtcdt-power-draw/
http://www.multitech.net/developer/products/accessory-cards/mtac-lora/mtac-lora-power-draw/Kind regards,
LeonModeratorFor the question about deep sleep not being supported on the mDot, please see the section “Deepsleep functionality change” on page…
https://developer.mbed.org/platforms/MTS-mDot-F411/I believe the hardware team designed in JP5 in order to ensure the xDot could be isolated from the developer card prior to having a complete understanding of what could be accomplished in software. In software, we are programming the IO as analog no pull. So leaving the connections in place (JP5 removed) has no impact on power draw.
I have tested a couple xDots using the AT command application and I am measuring 1.6uA in sleep. The AT command application can be downloaded here: http://www.multitech.net/developer/downloads/#xdot
Can you try that and see what you measure?Kind regards,
LeonFebruary 23, 2017 at 12:14 pm in reply to: Lowering Current consumption and unused MDot pins! #17431ModeratorHi Ajay,
Sounds good. Have you taken power measurements yet?
Kind regards,
LeonModeratorHi Ajay,
Yes, pins are configured as analog no-pull in deep sleep.
Upon entering deep sleep…
1. external pin configurations are saved
2. all possible internal and external pins are set to analog no-pull
upon waking…
3. external pin configurations are restored
Yes, the pins will be restored to whatever you had them configured as before deep sleep.If you invoke sleep rather than deep sleep, the external pin configurations are left to your discretion. Only internal pins are set for analog no-pull. This is in case you have attached components that require a certain state to achieve maximum power savings. Configure the rest as analog no-pull. This is where the example code would be particularly helpful.
I think it would be good practice to initialize any unused pins as analog no-pull. I’m not sure what state they come in by default. This should just be part of you power up initialization. No need to do it upon waking as waking from deep sleep restores them and sleep never touches them.
Kind regards,
LeonModeratorHi Ajay,
Since analog no-pull is the least power usage, I would initialize any unused pins as such. Unless your application changes their configuration, I would expect them to remain as analog no-pull through sleep and wake. You shouldn’t have to re-initialize them on wake up.
Kind regards,
LeonModeratorHi Ajay,
If you are using our libmDot-mbed5 or libmDot-dev-mbed5 library code version 2.0.15 or later, all the IO will be taken care of for you in deepsleep. In sleep mode the internal IO are taken care of but the external IO are left to your discretion. So in sleep mode, you can set external IO to remain in whatever state your attached equipment requires. If none of those pins are attached to anything, use deep sleep.
Are you familiar with our example code? This shows what we do with the IO in the libmDot libraries.
https://developer.mbed.org/teams/MultiTech/code/Dot-Examples/
The following functions in dot_util.cpp save, configure and restore IO. For lowest power consumption analog no-pull is recommended.
void sleep_save_io()
void sleep_configure_io()
void sleep_restore_io()Kind regards,
LeonModeratorHi Heath,
I don’t know if you performed a search for “US to Australia AC adapters” but maybe just such an adapter will fit your needs.
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=US+to+Australia+AC+adaptersKind regards,
LeonModeratorRobert,
One correction on that. After waking, it looks like there needs to be a 1s pause then +++ and a 1s pause after. So +WD would need to be at least 2s plus the time to send +++. The reason for the 1s before and after is so that is does not escape serial data mode with any +++ in the data stream. That said, I think the guard time should be much shorter than 1s.
Kind regards,
LeonModeratorHi Robert,
I’m assuming you are using our AT command firmware with +NJM=2 and +SMODE=1. It looks like escaping can be tricky. I want to dig into it a little more but from what I see there is a brief window of time, starting about 2s after reset, where you can issue a single ‘+’ to escape. Of course, that assumes you have control of the reset line. Otherwise, it appears you can issue ‘+++’ when it wakes during serial mode but the ‘+++’ can’t begin until it is awake and needs to be entered 1s before the +WD timer expires. So if you try it by hand, you need the timer set to 3000ms or so unless you are really quick.
FYI, I tested with version 2.0.16 of our AT command code.
Kind regards,
LeonModeratorHi Robert,
Do you have the mDot or xDot? If you have the mDot and have access to the debug port, there is an easy way to clear settings. You just need to enter characters on the debug port, upon reset, to enter the boot loader. You will see:
bootloader :>
At that prompt type ‘delete lora.cfg’ but without the quotes. That will clear the configuration.Kind regards,
LeonModeratorHi Yogesh,
Sorry, I was providing you with information straight from the ST Micro datasheet. I have not explored running the I2C interface faster than 400kHz. Here is a link to the datasheet for the processor we use on the mDot. Please see section 3.21.
http://www.st.com/content/ccc/resource/technical/document/datasheet/b3/a5/46/3b/b4/e5/4c/85/DM00115249.pdf/files/DM00115249.pdf/jcr:content/translations/en.DM00115249.pdfIf speeds greater than 400kHz are critical to your application, I can reach out to ST Micro to see what is required to exceed 400kHz.
Kind regards,
LeonModeratorHi Yogesh,
In both the data sheet and the reference guide for the mDot processor, it states that the I2C interface supports the standard (up to 100 kHz) and fast (up to 400 kHz) modes. Both documents also say that the I2C bus frequency can be increased up to 1 MHz but to contact a ST sales rep for details.
The I2C master provides the clock but there is some internal clock configuration that occurs under the hood on slave devices. So it might be necessary even though it does not generate the clock. Configuring the clock in slave mode shouldn’t hurt anything.
Kind regards,
LeonFebruary 3, 2017 at 3:44 pm in reply to: Cannot receive data send by MTDOT-BOX-G-915 on Node-RED #16687ModeratorHi Akshay,
I don’t see payload data in the debug of the screen shot you provided. Is the screen shot from survey or demo mode? Can you show what you get for each mode?
Kind regards,
LeonModeratorHi Kaz,
I think the issue is with your probe pin. D13 is not a defined pin for the mDot. Pin PA_5 of the mDot routes to D13 on the UDK2 board. If you look at the PinNames.h file in the path mbed-os\targets\target_stm\target_stm32f4 you’ll see that PA_5 can also be referenced as XBEE_AD2 and XBEE_DIO2.
If that does not solve it, I’d suggest you verify that you have control of the correct pin by setting it as either a digitalin or digitalout then read or set levels and confirm.
Kind regards,
LeonModeratorHi Akshay,
Connect to the Conduit’s debug port and issue ifconfig to check its ethernet settings.
http://www.multitech.net/developer/products/conduit/connecting-to-the-debug-interface/Kind regards,
LeonModeratorHi Kaz,
Correct…
“So, as far as I understand since I’m not good at reading datasheets, for 3.3V operation I have to desolder that tiny R118 registor (0 ohms) and put my multimeter between JP90.1 and JP90.2.”It will not affect the Arduino header voltages.
Sorry… the jumper next to the mDot by the right angle antenna holder grounds or un-grounds the right angle antenna holder.
Kind regards,
LeonModeratorHi Kaz,
See page 47 of the following document.
http://www.multitech.com/documents/publications/manuals/s000612.pdf
It is between JP197 and JP98. It has 5v and 3.3v written next to it.
To see the electrical connections, look for JP90 in area D3 of the schematic on page 55 of the document.
The UDK2 PCB may not have a corresponding JP90 marking on it.Also see pages 24 and 25 of the following for power draw.
http://www.multitech.com/documents/publications/manuals/s000612.pdf
Sleep mode can get you down around 40uA.Kind regards,
LeonModeratorHi Matt,
The current design of the xDot library only configures one pin for wake up but you can indepently configure other pins as InterruptIn to wake up the device. However there are limitations in the processor. It is not possible to use both the WAKE pin and GPIO2 simultaneously as wake up sources. WAKE is on PAO and GPIO2 is on PB0. Only one or the other can be an interrupt source not both. See InterruptIn limitation here: https://developer.mbed.org/platforms/MTS-xDot-L151CC/#xdot-pinout-diagram
Kind regards,
LeonModeratorHi Akshay
You can drag a function node into NodeRED and write code in it. You can write the function code in your favorite editor then cut and paste into the function node. The video also shows a method of importing. Do whatever works best for how you like to work.
Here is a link for writing functions in NodeRED
https://nodered.org/docs/writing-functionsKind regards,
LeonJanuary 27, 2017 at 9:02 am in reply to: How can I program for mdot models that are without programming header? #16501ModeratorHi Mark,
If you require the ability to program in system, your target board should route the programming pins to a header that you can access for programming. If you wish to load a custom application on the mDot but do not need to program in system, you can have Multitech setup a special SKU for you with your application programmed at the factory.
Kind regards,
LeonJanuary 26, 2017 at 11:41 am in reply to: Not understanding payload from mDot Box in node-RED #16480ModeratorHi Jeffrey,
As you already discovered, you need to use byte format not UTF-8. UTF-8 will not represent values above 0x7f in one byte. The following link details UTF-8.
https://tools.ietf.org/html/rfc3629As for your payload, the debug output is displaying it as decimal but our documentation is in hex. Your payload is:
14, 255, 255, 15, 8, 6, 2, 111, 5, 0, 77, 11, 1, 208
From the link http://www.multitech.net/developer/software/dot-box-and-evb-software/data-packet-format…
0x0E or 14 decimal is ‘Acceleration 3-Axis Measured’. So it contains 3 bytes of data. In your case, 255, 255, 15. The next set of data starts with 8 which is pressure and has 3 bytes. So 6, 2, 111. Next is 5 which is lux and is given in 2 bytes as 0, 77. Last is 11 or 0x0B for temperature with 1, 208.Again looking at the data-packet-format page, you see that the temp value is 0.0625 Degrees C (Signed MSB). First take 1, 208 and convert to a full 16 bit value. The first byte is trivially 0000 0001. The second byte is decimal 208 or 1101 0000 or 0xd0.
Combining the two bytes yields a hexadecimal value 0x1d0 or 464 decimal… 464 x 0.0625 = 29°C.Kind regards,
LeonModeratorHi Grant,
The device ID is not supposed to be changed as it is a uniquely assigned value.
From the LoRaWAN spec.
“The DevEUI is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device.”
Kind regards,
LeonModeratorHi Yogesh,
That message means it read a file but the file it read was of a size that did not match what it should be. I’m not sure how that would have happened. Can you see if reading the device ID works? The call is getDeviceId(). It should return the device ID that is on the sticker of your mDot.
Is your application using the file system? Is the file system not working for you?
Kind regards,
Leon -
AuthorPosts