Upcoming exciting (but breaking) Dash firmware and library changes


#1

Hello everyone,
We’re excited to announce that we are in the home stretch of the next version of our firmware. This version is going to include some new features that many of you have been requesting for quite some time. These new features include:

  • Custom topics on cloud messages
  • Simpler SMS receiving using a callback and with a sender number and timestamp
  • Signal strength function
  • Modem power off
  • Better feedback on sending messages
  • Connect/disconnect with success/fail reasons

This should all be released sometime in the range of the 16th to the 23rd.

The process for getting all of these working involved a significant revamp of our firmware, IPC subsystem and hardware API.
As a result, we need to release a new version of the Arduino IDE integration alongside this new version of the system. Your current source code will be compatible with these changes, however the binaries will not. This means you will need to recompile your code with the new Arduino IDE Integration in order for it to work properly with the new system firmware.

We know this will be an inconvenience to some of you, but these new features and revamped codebase will now be available in your future program for you to enjoy. This revamp will also allow us to quickly release even more cool features like:

  • Receiving inbound data messages for control and configuration
  • Better encryption
  • More reliable and secure OTA updates

We’ve been working hard to bring all of this cool stuff to you and are excited to get it out into the world.

Please feel free to leave questions and comments in this thread.


Dash Firmware and Arduino Integration Updates
#2

#3

Hi Reuben…thanks for the update. Looking forward to trying out the new features ! Are you able to elaborate on the future feature noted…Receiving inbound data messages for control and configuration? Also, is there any plan to provide access to network time? If so, is this something that will be available near term?
Thanks !!


#4

All of this looks great, Reuben. You and your colleagues have been busy! Looking forward to the features – custom topics, clock, enhanced SMS, signal strength, connect / disconnect will be greatly appreciated.


#5

Network time is on the list, but may slip to the next release depending on how long other things take. We’ll keep you posted.


#6

Thanks…Great news! Are you able to elaborate on future feature “Receiving inbound data messages for control and configuration”?


#7

Basically it’s an alternative method to SMS for getting data down to your device.


#8

Thanks…Look forward to seeing how it works.


#9

I am really looking forward to the “Modem power off” feature. All of my potential applications are battery operated and require a truly low current deep sleep.

Are there going to be better hooks on tracking the state of the modem (connected, message sent, etc.)? I need to be certain that all message have been sent before turning off the modem and I need to wait for the connection to be up before sending messages. I believe I am seeing dropped messages if I use SerialCloud.println before I have a connection.

I have functions that parse the debug messages to track the modem state, but this is inefficient and a week link if you decide to change or turn off the debug messages.

Is all that covered under “Better feedback on sending messages” and “Connect/disconnect with success/fail reasons”?


#10

I would like more information the “Modem power off” as well. My projects will have to be powered by battery and solar and need to be very low powered. I’m using an SD card to store the data from the sensors and then having the device send information at intervals to minimize continuous power usage.

I have seen the data sheet for the NXP Kinetis K22F chipset and it seems there are a number of different power modes available to allow partial functionality.

Are any of those being added to the library, or if not in the near future, how would I go about accessing them directly?


#11

Modem power off will definitely improve your power usage. We’ll have more details about this soon. Expect a full refresh of the Dash API docs when we release that will explain how to use all of these new features.

For the Kinetis chip, we already support various sleep modes. See https://hologram.io/docs/reference/dash/api#power-management

Edit: I should add that while power usage will be lowered by turning off the modem, there’s of course a lot else that goes into this and we’ll have a bigger power usage update soon.


#12

Yep, everything will be handled with callback functions instead of having to parse debug messages.


#13

The new firmware and Arduino IDE are now live!

You should get an alert in your IDE or you’ll see the update is available if you go into the boards manager. This firmware has so much cool stuff in it. I’d recommend as a starting point you take a look at the Examples menu in the IDE and look for the ReadEvalPrint sketch. This sketch installs a console on your Dash that lets you type in commands to test out each of the features.

When you go to upload to the board the first time, it’ll alert you about the new system firmware version. Remember that you need to install this version in order for anything to work.

I hope you guys enjoy playing with this new version. Please let us know if you spot any issues.
Documentation has been updated with all of these new API calls and is available at https://hologram.io/docs/reference/dash/api/


#14

FYI network time did make it into the release


#15

A lot packed into the new release. All great stuff! Thanks !


#16

I have some questions after reading through the updated documentation. It looks like the HologramCloud object is maintaining a single outgoing message buffer. Based on my reading of the documentation, there are four methods for manipulating that buffer.

HologramCloud.write(x) resets the content of the buffer and puts a single byte into it, but does not initiate a send.

HologramCloud.sendMessage(params) appends the new content to any existing content and blocks until the content is sent or fails.

HologramCloud.sendMessage() blocks until the existing content is sent or fails.

HologramCloud.print() is mentioned in the sendMessage discussion but not defined.

Here are my questions:

  1. If HologramCloud.sendMessage(…) is blocking, what is the maximum time it will block?

  2. Are there any non-blocking calls to send the message buffer content and if so, what are they and what are the calls to determine send status?

  3. In the context of HologramCloud.write(x), does “reset” mean empty any previous content of the message buffer? Given that all calls to send a message appear to be blocking, I am not sure what else it could mean. If it does mean to empty the buffer, I am not sure what this function is to be used for.

  4. There is no documentation for HologramCloud.print(). Does it have the same signatures as Serial.print()?

  5. Is HologramCloud and extension of Serial?

  6. Is the Clock class persistent across calls to Dash.deepSleep?

  7. Will the Clock alarm functions wake the Dash out of deep sleep?

  8. For the Clock.wasReset() function, what are the causes of clock reset?

Thanks for your assistance.


#17

Amazing release. Thank you!


#18

@Andrew

Thanks for your questions and we’ll be using them to improve the clarity in the documentation. I’ll answer your specific questions here and we’ll be updating the documentation over the coming days.

It’s probably most helpful to start with an example to see the features used in code. From the IDE select

Examples/DashExamples/hologram_dash_cloud

or on Github

That walks you through using HologramCloud.

On to your questions…

  1. If HologramCloud.sendMessage(…) is blocking, what is the maximum time it will block?

To send a message the modem has to be powered, associated with a tower, and connected to the network. Worst case would be the modem is powered off (HologramCloud.powerDown()) and sendMessage is called. You can call HologramCloud.sendMessage without explicitly calling powerUp or connect.

HologramCloud.powerUp() can take several seconds for the modem to fully boot after being powered down. Once booted, the modem attempts to associate with a tower asynchronously.

HologramCloud.connect() has a hard timeout at 3 minutes, but will most likely return within 2 minutes. The major factor here is cell coverage. If in range of a tower, this call will be < 1 second.

sendMessage will return in < 1 second if already connected and in cell coverage.

To minimize blocking, you can call HologramCloud.getSignalStrength() to check for coverage. If that call returns 99 (no coverage), then you may want to skip the HologramCloud.sendMessage() call.

  1. Are there any non-blocking calls to send the message buffer content and if so, what are they and what are the calls to determine send status?

All the HologramCloud.sendMessage() calls are blocking. Using the signal strength strategy above will minimize blocking time.

  1. In the context of HologramCloud.write(x), does “reset” mean empty any previous content of the message buffer? Given that all calls to send a message appear to be blocking, I am not sure what else it could mean. If it does mean to empty the buffer, I am not sure what this function is to be used for.

The docs description for HologramCloud.write(x) is misleading and will be changed. That call will add a byte to the message buffer.

  1. There is no documentation for HologramCloud.print(). Does it have the same signatures as Serial.print()?
  2. Is HologramCloud and extension of Serial?

HologramCloud implements the same print and println functions that Arduino Serial uses. Calling those functions adds the output to the message buffer.

The message buffer consists of the message contents and the tags. The buffer is ‘fixed’ once a sendMessage call is made so that the same message can be resent with HologramCloud.sendMessage() (no parameters). This is useful if a message send failed and you want to try the same message again without re-printing to the buffer.

The buffer contents are retained after a call to sendMessage until the buffer is written to again. This is best demonstrated by example:

//write a message to the buffer, 
HologramCloud.print("Value: ");
HologramCloud.print(32);
//buffer contents are now "Value: 32"

bool success = !HologramCloud.sendMessage(".00");
//Now the buffer contents are "Value: 32.00" and the message was sent
if(!success) {
  //failed, so let's try again in 30 seconds...
  Dash.snooze(30000);
  
  //We haven't changed the buffer since the last call to sendMessage, so send the same message again:
  //"Value: 32.00"
  HologramCloud.sendMessage();
}

HologramCloud.sendMessage("Hello, World!");
//this call changes the buffer since the last sendMessage, so we start a new message
//Buffer contents: "Hello, World"

//Let's send "Hello, World!", since it is still in the buffer
HologramCloud.sendMessage();

HologramCloud.print("It was the best of times, it was the blurst of times");
//This is the first write to the buffer after sending, so start a new message
HologramCloud.sendMessage();
//Send the contents of the buffer, "It was the best of times, it was the blurst of times"
  1. Is the Clock class persistent across calls to Dash.deepSleep?

The Clock class controls the Real-Time Clock on the Dash. This clock counts seconds while the Dash is powered. Only completely removing power from the Dash resets this clock, which starts at Jan 1, 1970 00:00:00. Resetting the Dash user processor, programming the Dash, and putting the Dash in sleep or deep sleep does not affect the Clock. It continues to tick as long as power is applied.

  1. Will the Clock alarm functions wake the Dash out of deep sleep?

The alarm will wake the Dash from deep sleep and that is demonstrated in the hologram_dash_cloud example sketch referenced above.

  1. For the Clock.wasReset() function, what are the causes of clock reset?

Clock.wasReset() returns true only if the Clock was reset on the last processor boot, meaning power was just applied. You can use that function to check if the time needs to be updated. And if you are within cell coverage, just sync the clock to network time!

rtc_datetime_t dt;
if(HologramCloud.getNetworkTime(dt)) {
  Clock.setDateTime(dt);

I hope this can help you move forward with the new cloud interface!


#19

Thanks for the answers. I like the power down and RTC features. It does help, but it brings up a few issues for me.

My application includes a bridge between a Zigbee network and the cloud and it operates off a battery for long periods of time. We have a prototype built using a Raspberry PI with one of your USB cellular modems. Due to the high power requirements of the PI we built a hat with the Zigbee radio and a PIC processor that controls power to the PI.

Most of the time everything is in deep sleep. Periodically the PIC wakes up, checks sensors and turns on the Zigbee network. If it finds something of interest it wakes up the PI, hands off a packet to be sent to the cloud, and then continues processing Zigbee traffic and sensors until the PI indicates it is done. Then the PI is powered down again.

I have been eagerly waiting for the Dash to be ready, because it should simplify what we are doing, and it is getting closer. Powering down the modem is a big step in that direction.

For me, the blocking calls to HologramCloud are a significant issue. It means that I cannot be checking sensor or servicing the Zigbee network while I am sending messages to the cloud. For the next iteration of the API, can we get non-blocking send calls and either a method to get the send status or a callback function on completion?

With the right power control and separation between the control processor and the modem processor on the Dash I would be able to ditch the PIC and hook the Zigbee radio up to the Dash. Is this potential somewhere on the road map?


#20

Hi, Reuben,

Is there a call to reboot / restart the Dash? It would be cool (in some cases) to be able to have the Dash restart, or to issue a remote restart command.

Thanks!