Ryan Klaassen
Forum Replies Created
-
AuthorPosts
-
Ryan Klaassen
BlockedAn external flash would need to be added to the xdot to store the firmware image coming down, or a host processor could use extended at+rxo to allow a host processor to reconstruct that binary and flash the xdot. The host processor would need somewhere to store the firmware image.
Ryan Klaassen
BlockedIt can be done from LENS and AEP.
Ryan Klaassen
BlockedYes, and fota is fully implemented on the mDot.
Ryan Klaassen
BlockedThe xDot does not have external flash to store the firmware image. We are extending serial data mode so the xDot will send the packets to another processor. That processor will have to reconstruct the firmware image, and then flash it into the xDot using the xDot’s bootloader.
January 30, 2019 at 3:39 pm in reply to: xDot modult working with the Semtech Stack version 4.4.0 #27125Ryan Klaassen
BlockedAny success with the port?
December 28, 2018 at 11:08 am in reply to: Downlink Data being received on Port 0, resulting in invalid MAC Command errors. #27010Ryan Klaassen
Blockedyou can specify a port using MQTT ex:
snprintf(payload, sizeof(payload), "{\"data\":\"%s\",\"ack\":false,\"port\":%u}", buf, 1);
then publish
mq.publish(NULL, topic, (int)strlen(payload), (void*)payload, MQTT_QOS_1)
December 27, 2018 at 2:55 pm in reply to: Downlink Data being received on Port 0, resulting in invalid MAC Command errors. #27008Ryan Klaassen
BlockedThe mDot receives on all ports. Port 0 is reserved for mac cmds only. Other ports such as 224 is dedicated to LoRaWAN Mac layer test protocol.
There are ways on the conduit to set the downlink port. What are you using to send lora packets on the conduit?
Ryan Klaassen
BlockedThe ON_SLEEP pin is describe here http://www.multitech.net/developer/software/mdot-software/at-command-firmware-user-guide/ under serial data mode.
The Serial Data mode is designed to work in conjunction with sleep where the mDot wakes up periodically, signals a host, reads data from the serial port, and then transmits it. The mDot can be configured to wake up on a fixed time interval or on an interrupt triggered by the DIO7 pin. When the mDot wakes up in serial data mode, it sets the XBEE_ON_SLEEP pin so the host processor knows when to start transmitting serial data.
Ryan Klaassen
BlockedI don’t see anything in the code that stands out as the issue.
https://github.com/ARMmbed/mbed-os/pull/4734/files It may have something to do with this pr. In 5.5.4 they eliminated some clears specifically this call __HAL_UART_CLEAR_IT(huart, UART_CLEAR_TCF); on uart_irqRyan Klaassen
BlockedI apologize, I meant what is the INT_USART1_TX_Handler code?
Ryan Klaassen
BlockedThis is the only change I could find on interrupts from 5.5.3 to 5.5.4.
https://github.com/ARMmbed/mbed-os/pull/4676 . What is &INT_USART1_TX_Handler doing?Ryan Klaassen
BlockedDoes the interrupt go through the ISR without going to sleep?
-
This reply was modified 6 years, 5 months ago by
Ryan Klaassen.
Ryan Klaassen
Blockedtry setting the mode to pullup or pulldown
Ryan Klaassen
BlockedAdd a bool and set to true on rise of the pin on interrupt. Set to false before sleep. Check if true then the pin was the cause, else it was the rtc.
Ryan Klaassen
BlockedIn AU915 peer to peer, the valid datarates are 8-13.
Ryan Klaassen
BlockedWas the dot box in configuration mode when trying these two ports? Try typing AT.
Ryan Klaassen
BlockedIt will flash a new mbed program for the mdot.
Here is information:
https://www.multitech.com/documents/publications/manuals/s000612_DB9.pdf
Ryan Klaassen
BlockedThere should be two serial ports enumerated, if only one is coming up which one is it?
Ryan Klaassen
BlockedXdot tbd. Mdot will pushed up today.
Ryan Klaassen
BlockedIt may be due to the time it takes to process a packet or when the packet was recv. The timer will keep running until the packet is verified for that device. Once the packet is verified the ack timer gets killed. It may be the device verifies the packet just after the timer expires, where the print happens but the callback doesn’t.
Ryan Klaassen
BlockedDoes the join delay match on both ends? There are a lot of SPIFFS errors as well. Do you normally see this many SPIFFS errors? The flash may be corrupted on the dot.
Ryan Klaassen
BlockedHere is some example code https://os.mbed.com/teams/MultiTech/code/Dot-Examples/
Ryan Klaassen
BlockedYou can edit the file located in /var/config/lora/lora-network-server.conf
Change the value for eui and key.Then restart the network server using
$ /etc/init.d/lora-network-server restartHere is a link for more information.
Ryan Klaassen
BlockedThere is a key management tab under the LoRaWAN section
Ryan Klaassen
Blockedat+ni=0,(hex value)
at+nk=0,(hex value)Ryan Klaassen
BlockedDo these settings match the conduit?
AT+PN=value (value = Network Setting from your Conduit)
AT+JD=value (value = Join Delay from your Conduit)
AT+FSB=value (915 NA only | value = frequencySubBand from your Conduit)
AT+NI=1,value (value = Network Name for your Conduit)
AT+NK=1,value (value = Network Passphrase for your Conduit)Ryan Klaassen
BlockedThe dot lib is compiled using a certain version of mbed-os. Make sure the version of mbed-os you are using matches the mbed-os version that the dot lib was complied against.
Ryan Klaassen
BlockedConfiguration can be done using at commands.
Activation mode is at+njm=2 for auto ota
Device class is at+dc=c for class c
Network mode is at+pn=2 for privateRyan Klaassen
BlockedThe code works on my end. Can you confirm you are using mbed-os-5.4.7 and GCC 4.9?
cmd for GCC arm version: mbed config GCC_ARM_PATH
cmd for mbed-os version: git describe –match mbed-os*Ryan Klaassen
BlockedFor AT cmds: AT&K Hardware Flow Control AT&K0: disable, AT&K3: enable
For xDot library: int32_t setFlowControl(const bool& on); -
This reply was modified 6 years, 5 months ago by
-
AuthorPosts