• State Verified Answer
  • Replies 8 replies
  • Subscribers 87 subscribers
  • Views 1105 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 257278
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thingy91 skipped orange breathing during setup

cachro2

Hi,

I received a Thingy91 and am unable to commission it to nrFCloud.

The Thingy91 skipped orange breathing as mentioned in the manual here (step 4). It went directly to cyan breathing which is weird since I believe it thinks it is associated to the cloud..

It was purchased brand new a few days ago and SIM card is activated through the nRF Cloud portal.

Before I go ahead and update modem firmware and the such, any thoughts?

Thanks,

Robert

Parents
  • 0

    Hi!

    The manual you linked to is an older version with incorrect information. The newest Thingy:91 Getting Started Guide v1.3 states that the cyan color means that the device is connecting to nRF Cloud. So that can take a few minutes and then when it starts to blink yellow, your device is connected and is awaiting user association. 

    When it is connected to nRF Cloud and sending data, it will flash a dark blue.

    However, it is important to update both the application firmware and the modem firmware on the nRF9160 SiP before beginning. You can take a look at our Thingy:91 Getting Started video for easy information on how to do this. 

    Best regards,

    Heidi

  • 0 in reply to Heidi

    Thank you Heidi, we are up and running!!

    One additional question:

    I scanned the manual and didn't find a concrete answer. Is there a spare UART peripheral exposed and accessible on the Thingy91? I ask because our prototype asset tracking units need to pull data from an external microprocessor to function properly.

    Thank you,

    Robert

  • 0 in reply to Heidi

    Heidi,


    Thank you again!

    I took a look at the Thingy91 schematic and it seems like the I2C2 reads/writes to environmental sensors + EEPROM, etc. and the SPI3 maps to the two accelerometers. I cannot tell what the two UARTs (UART0 and UART1) are mapped to by looking at the schematic. Likely a connection between the nrf52840 and nrf9160 is one of them and perhaps GPS another?

    Can you please point to where these peripherals are defined in the asset_tracker code? I am having difficulty locating any mention of UART0, UART1, I2C2, etc.

    Best,

    Robert

  • +1 in reply to cachro2

    Yes, I2C2 for sensors, SPI3 for accelerometers. UART0 is for communication between the nRF9160 and the nRF52840. And UART1 is to be able to get modem tracing from the modem on the nRF9160 SiP. 

    This file (src/env_sensors/bsec.c) is where I2C is used. This line is the initialization of the I2C2 peripheral. It is also used in the temperature sensor, see the BME680 driver.

    As for SPI3, the Thingy.91 uses the accelerometer ADXL362. If you take a look at the driver for this sensor, you can see it uses SPI. 

    As for the UART peripherals, I don't think there's any specific mention of them in the application This BSD Lib config, CONFIG_BSD_LIBRARY_TRACE_ENABLED enables UART1.

    And if you dig around in the logging module (see log_backend_uart.c), you can see that it uses UART_0 by default.

    So, if you enable logging over RTT instead of UART, UART_0 is free and I believe you then get one available UART peripheral that you can use for something else. 

  • 0 in reply to Heidi

    Thank you Heidi, we ended up salvaging two GPIO pins by cutting traces running from the Thingy accelerometers to nrf9160 P0.07 and P0.08. (TP37 and TP38). We are now soldering wires directly to these two test points and using them as inputs for our external rotation device which tracks counts. 

    We also decided to use the mqtt_simple firmware on the Thingy91 from the nRF SDK to push raw data to our AWS instance via MQTT. For our MVP prototypes, we did not yet need all the bells and whistles included in the Thingy91 firmware.

    That being said, I've got a few questions. Do you see any issues with us running mqtt_simple on this device?

    I ran a power draw test over the weekend and noticed that every 22 hours or so the Thingy stopped publishing data to our instance. Unfortunately, I needed to power cycle the unit with the on/off switch before it resumed posting. Do you know why this could be? I hope this is not an issue related to the inherent functionality of the PMIC.. Based on the schematic, it looks like the ADP5360 PMIC is controlled by I2C which is obviously not part of the mqtt_simple firmware. Perhaps, if possible, we need to reset the radio in the mqtt firmware every so often?

    Time Voltage (V) Data Used (Mb)
    11/6/2020 3:30pm 4.14 0.26
    11/7/2020 2:52pm 3.99 1.95
    11/8/2020 6:30pm 3.87 3.73
    11/9/2020 8:10am 3.80 4.70

    Also according to the documentation, the EEPROM onboard the Thingy apparently is critical for correct operation and should not be changed. Can you please elaborate what information is there and if it will affect our prototype units running the mqtt_simple firmware in the field?

    Thank you again Heidi, your support is much appreciated.

    Robert

  • 0 in reply to cachro2

    Hi!

    Would you mind making a new ticket for this issue?

    Best regards,

    Heidi

Reply Children
No Data
Related
Terms of service