Chad Goyette

Forum Replies Created

Viewing 30 posts - 1 through 30 (of 38 total)
  • Author
    Posts
  • in reply to: Conduit SMS Commands #28365
    Chad Goyette
    Participant

    can you provide a procedure for the manual edit? do i just set the SMS commands i want to enable to true in the db.json file? i have too many versions deployed to have one of each available.

    in reply to: Conduit SMS Commands #28362
    Chad Goyette
    Participant

    Will this method work with different models of the conduit? i have about 3 different versions out in the field, would i need to use a similar local conduit to do this for each, or can i use any model? is it possible to manually edit the config file without a conduit?

    Thanks

    in reply to: Conduit SMS Commands #28359
    Chad Goyette
    Participant

    Two questions, can you provide a link to the documentation that explains the SMS format, i cant seem to find it anywhere and i know i have viewed it in the past.
    Second, is there a way to remotely configure/ enable the SMS command feature? i have deployed conduits that i can only interact with remotely via cellular i dont see the option when trying to do a partial configuration. Im running v1.6.2 of the firmware.

    Thanks

    in reply to: FUOTA – ?'s, Details, and Use #27927
    Chad Goyette
    Participant

    does Multitech have any reference designs we could use to enable an xDot implementation to have FOTA ability? What are our options regarding getting the bootloader the information needed to access the flash? I would like to incorporate any needed hardware now while my PCB design is mid-spin.

    Thanks

    in reply to: FUOTA – ?'s, Details, and Use #27925
    Chad Goyette
    Participant

    Is a host processor required to flash the xdot? I am in the process of adding an external flash to my xdot implementation. can I just add the external flash or would I need other hardware to accomplish the update?

    in reply to: xdot/mdot operating frequency #27230
    Chad Goyette
    Participant

    Is it acceptable to print the CE label and place it on the device for the EU application?

    in reply to: FUOTA – ?'s, Details, and Use #27203
    Chad Goyette
    Participant

    so just for clarification, are you saying that you are working on a solution to implement FOTA on the xDot in its current configuration, or are you saying that external flash would need to be added to my xdot solution to allow FOTA to work?

    in reply to: FUOTA – ?'s, Details, and Use #27185
    Chad Goyette
    Participant

    does the mDot have external flash?

    in reply to: FUOTA – ?'s, Details, and Use #27181
    Chad Goyette
    Participant

    Any update on when this will be available for the xDot?

    • This reply was modified 5 years, 2 months ago by Chad Goyette.
    in reply to: Key managment / whitelist questions #26171
    Chad Goyette
    Participant

    Hi Jason,
    Just to make sure I’m following you, you’re saying I can reject nodes with my current setup if my application has a whitelist and clears join messages for nodes, not on the list. What I’m trying to avoid is my installers reprogramming edge devices in the field with custom credentials.

    in reply to: Conduit AEP Factory reset itself #19933
    Chad Goyette
    Participant

    Thanks Steve,
    I’ll try to save the config and hopefully, this solves the issue if it ever happens again. The devices are powered with the standard wall wart they came with. this was an odd problem since one of the devices has been running out in the field for close to a year with no issues. When the customer shipped it back to me I powered it up and it acted like a new box starting with the setup wizard.

    in reply to: lora network server logs documentation #19916
    Chad Goyette
    Participant

    Is this documented anywhere so I can reference as needed?

    in reply to: Transmit in Progress Error when sending packets. #19885
    Chad Goyette
    Participant

    Thanks Mark.
    I don’t believe this is a sleep issue since its not consistent (can sometimes take a week of running to happen) and i have many other devices that use sleep and don’t experience this issue. Is there an official answer to what may be happening? Also until i can get to the bottom of what is going on is there a recommendation on a method to detect this error so that i can force the xdot to reset? I tried the getIsTransmitting() and that doesn’t seem to change state when this event takes place.

    in reply to: Transmit in Progress Error when sending packets. #19508
    Chad Goyette
    Participant

    Mike,
    Below i was able to capture some logging when this error occurred. does this provide any insight to what is going on and what i can do differently?

    Data Change Detected…
    Sending data… Ack Status = 8
    [DEBUG] Send with tx timeout 40000
    [INFO] Preparing frame
    [DEBUG] ADR ACK CNT: 2 LIMIT: 64 DELAY: 32
    [TRACE] NA: 00000011
    [TRACE] NSK: 570a78ae3eaf97fb99185b0e252d983d
    [TRACE] DSK: e0e7fd41a9476b4e7981aca63d0e0690
    [TRACE] Adding MIC to frame
    [TRACE] Sending 17 bytes
    [TRACE] Number of available channels: 1
    [DEBUG] Using channel 64 : 903000000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX1 on freq: 923300000
    [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 13 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 1
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX2 on freq: 923300000
    [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 13 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 2
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [DEBUG] ACK timeout repMax: 1 ackMax: 8
    [INFO] ACK resend attempt: 2 / 8
    [TRACE] Number of available channels: 1
    [DEBUG] Using channel 64 : 903000000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 26
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 4 SF: 8 BW: 2 CR: 1 PL: 8 CRC: 1 IQ: 0
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX1 on freq: 923300000
    [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 14 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 1
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX2 on freq: 923300000
    [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 14 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 2
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 4 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [DEBUG] ACK timeout repMax: 1 ackMax: 8
    [INFO] ACK resend attempt: 3 / 8
    [TRACE] ADR Lowering datarate
    [TRACE] Number of available channels: 8
    [DEBUG] Using channel 7 : 903700000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX1 on freq: 923300000
    [TRACE] RX DR: 13 SF: 7 BW: 2 CR: 1 PL: 8 STO: 16 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 15 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 1
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 1 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [TRACE] RX2 on freq: 923300000
    [TRACE] RX DR: 8 SF: 12 BW: 2 CR: 1 PL: 8 STO: 12 CRC: 1 IQ: 1
    [TRACE] Stats: Up: 15 Down: 8 DupTx: 0 CRC Errors: 0
    [INFO] Rx Window 2
    [TRACE] Event: RX_TIMEOUT
    [TRACE] Flags Tx: 0 Rx: 0 RxData: 0 RxSlot: 2 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 3 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [WARNING] SEND TIMED OUT after 40000 ms
    [WARNING] Mac: ResetState
    [WARNING] Link: ResetState
    [ERROR] ACK not received
    Operation Timed Out – ACK not received
    Setting ack to ‘0’…
    ambient temp = 74.525002
    volt-check = 1.000000
    [TRACE] configuring RTC Alarm A to wakeup 15 seconds from now
    [INFO] entering sleep (stop) mode 00000037รกcsampleCount = 1
    hbCount = 7
    Linkcheck Fail count = 1
    Setting ack to ‘8’…
    [DEBUG] ACK timeout repMax: 1 ackMax: 8
    [INFO] ACK resend attempt: 4 / 8
    [TRACE] Number of available channels: 8
    [DEBUG] Using channel 5 : 903300000
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    [INFO] Configure radio for TX
    [DEBUG] Session pwr: 26 ant: 3 max: 21
    [DEBUG] Radio Power index: 20 output: 19 total: 22
    [DEBUG] TX PWR: 20 DR: 3 SF: 7 BW: 0 CR: 1 PL: 8 CRC: 1 IQ: 0
    Data Change Detected…
    Sending data… Ack Status = 8
    [DEBUG] mDotEvent – TxDone
    [TRACE] Event: OK
    [TRACE] Flags Tx: 1 Rx: 0 RxData: 0 RxSlot: 0 LinkCheck: 0 JoinAccept: 0
    [TRACE] Info: Status: 0 ACK: 0 Retries: 0 TxDR: 3 RxPort: 0 RxSize: 0 RSSI: 0 SNR: 0 Energy: 0 Margin: 0 Gateways: 0
    [ERROR] Transmit in progress
    Transmit Error – Transmit in progress
    Setting ack to ‘0’…
    ambient temp = 74.525002
    volt-check = 1.000000
    [TRACE] configuring RTC Alarm A to wakeup 15 seconds from now
    [INFO] entering sleep (stop) mode 00000037รกcsampleCount = 0
    hbCount = 8
    Linkcheck Fail count = 1
    Measuring Coupons…..
    Coupon 1 Test = 0.000000
    Coupon 2 Test = 0.000000
    Coupon 3 Test = 0.000000
    Coupon 4 Test = 0.999512
    Data Change Detected…
    Sending data… Ack Status = 0
    [ERROR] Transmit in progress

    in reply to: Transmit in Progress Error when sending packets. #19477
    Chad Goyette
    Participant

    Mike,
    Any update on this? I have another couple devices that i have found stuck with this problem (happens over period of time). Is there a way that you can suggest a way to detect and recover from this?

    in reply to: Transmit in Progress Error when sending packets. #19001
    Chad Goyette
    Participant

    Mike,
    I am running libxDot-mbed5 2.0.17-1 with mbed-os 5.4.2. This issue isnt something that pops up right away and seems to present its self over time. i have only experienced this with one device so far but i do expect a couple of my field installed devices may be experiencing the same issue. unfortunately i am not able to provide the application at this time.

    in reply to: Transmit in Progress Error when sending packets. #18978
    Chad Goyette
    Participant

    I am also interested in this error which i have recently been receiving, though on an xDot instead. I am running Private lora network with a custom app, US915mHz and most up to date libxdot-mbed5 with the appropriate mbed-os.

    in reply to: Maximum Voltage input to xDot #18290
    Chad Goyette
    Participant

    Thanks Darrik, I am trying to avoid the regulator to maximize battery life. Currently my setup does not require a constant voltage for reference which lead to the elimination of the regulator and allowed power consumption to be at 25uA during sleep. Do you guys have experience with a regulator that can support the higher load of LoRa transmission while having an extremely low standby current?

    in reply to: Maximum Voltage input to xDot #18184
    Chad Goyette
    Participant

    Is anyone able to answer this for me?

    in reply to: LoRa custom message descriptor #17987
    Chad Goyette
    Participant

    Thanks for the response. Is this the purpose of this field or does it serve some other function as well? Is there any documentation on what this call does or its purpose other than whats in mDot.h?

    in reply to: mbed cannot find xDot_L151CC target #16497
    Chad Goyette
    Participant

    mbed-os revision = 2246:a6f3fd1 (5.1.5)
    libxDot-mbed5 revision = 7:aff2c05 (2.0.14)

    I am using the online compiler. you should experience same results of you try to run the DOT-Examples code. with libxDot-mbed5 and set to the xDot platform.

    • This reply was modified 7 years, 3 months ago by Chad Goyette.
    in reply to: LoRa Range problems #16393
    Chad Goyette
    Participant

    Tom,
    I have done similar range testing with my mDots (conduit on my desk and drive around with mDots) and have had similar range results as you. The range issue (assuming all else is normal) that you are experiencing is likely due to the conduit being inside your building, and the construction of the building leading to interference. To solve this problem i mounted my conduit outside in a weather rated box with a fiberglass ~5′ omni antenna mounted to the roof of a 30′ building. Range testing now results in approximately 1.5 to 2 miles driving around an urban area.

    in reply to: Problem configuring xDot analogIn pin #16280
    Chad Goyette
    Participant

    Ok i tried the HSI clock restart and that worked. is there a more permanent fix for this or is this the best we have at the moment?

    in reply to: Problem configuring xDot analogIn pin #16279
    Chad Goyette
    Participant

    I have tried both deepsleep true and false with no change.
    mbed-os version 2246:a6f3fd1 which should be 5.1.5.

    in reply to: Problem configuring xDot analogIn pin #16277
    Chad Goyette
    Participant

    I just tried this with no luck.

    in reply to: Problem configuring xDot analogIn pin #16275
    Chad Goyette
    Participant

    I just created very simple helloworld program that is demonstrating the issue. on the first loop i am reading the ADC correctly, on the second loop and then on it will read 0. I am using libxDot-mbed5 revision 7:aff2c05 and all the dot examples supporting files.

    ————————————————————
    #include “dot_util.h”
    #include “RadioEvent.h”
    #if ACTIVE_EXAMPLE == HELLOWORLD

    //AnalogIn tmp3(PB_0);
    mDot* dot;

    main()
    {
    dot = mDot::getInstance();
    int a = 0;
    while(1)
    {
    AnalogIn tmp3(PB_0);
    a++;
    uint16_t TC = tmp3.read_u16();
    printf(“Raw thermistor reading is %i\r\n”, TC);
    printf(“Hello World this is the Target Device %i\r\n”, a);
    //wait(1);
    delete &tmp3;
    dot->sleep(5, mDot::RTC_ALARM, false);
    }
    }
    #endif
    —————————————————————-

    in reply to: Problem configuring xDot analogIn pin #16273
    Chad Goyette
    Participant

    *xDot is on a custom board.
    *the device is being powered with 3.3v from a test power supply.
    *This particular input is connected to a 10k thermistor with a voltage divider circuit.
    *I have tried additional unused pins that where left floating (open) with same result.

    For code I am using the dot examples auto_ota as a template (basically using all the startup stuff and then replacing the “guts with my code”. My custom board uses two inputs PB_0 on the ADC, and PB_14 as a digital in. The digital in object works fine.
    if the board doesn’t go to sleep the ADC works as expected, once it sleeps i only get 0. I have tried what you suggested creating and destroying the object before and after sleeping but that is not changing the result.

    in reply to: Problem configuring xDot analogIn pin #16266
    Chad Goyette
    Participant

    I tried this and this doesnt seem to work. It seems that once the xdot goes to sleep i lose the ability to configure the pins to use the adc.

    in reply to: xDot Programming trouble #16225
    Chad Goyette
    Participant

    Tom I finally got around to trying your recommendation and I am finding that this procedure is not working correctly. I swapped the JP30 jumper to JP5 plugged in the programming head as you specified and made sure that my target board was powered up and confirmed that power was seen on the UDK before plugging it into the USB. When I plug the UDK in the USB drive shows up as maintenance so my first thought was we have a problem. We looked through our schematics and we are sure that we are connected correctly based on the information in the developers guide. I am also confident that our xdot connection to the interface board is good.

    As a work around I installed the JP5 jumper back onto JP30 then I tried installing a simple “Hello World this is the UDK” program on the UDK with nothing hooked up to it. I then hooked up my powered target device and reset the USB connection then installed a “Hello World this is the target device” program. after confirming that this program was properly sending messages to the serial console I then unhooked the target device reset the USB and opened the serial console which now displayed “Hello World this is the UDK” confirming that the first program was still on the UDK and the previous program was definitely on the target.

    So lesson learned unless there is an other way to isolate the UDK xdot it would be good practice to have a warning program on the UDK running that the user can confirm through the serial console that they are not able to see the UDK message before programming the target.

    in reply to: mDot Time between transmits using libmDot-mbed5 #15284
    Chad Goyette
    Participant

    Understood,in addition to disabling ACK’s I also have setTxWait disabled which should ignore the Rx windows but its not. I actually have no change when setTxWait is either enabled or disabled.
    /** Enable/disable TX waiting for rx windows
    * when enabled, send calls will block until a packet is received or RX timeout
    * @param enable set to true if expecting responses to transmitted packets
    * @returns MDOT_OK if success
    */
    int32_t setTxWait(const bool& enable);

Viewing 30 posts - 1 through 30 (of 38 total)