Dash and Dash Pro Hardware Discussion


#1

Hello again backers!

We have some exciting updates about the Konekt Dash and Dash Pro to share with you!

More changes based on what YOU told us!

The biggest change we’ve made has been based on your feedback and concerns about reducing data consumption to make your data plans last longer. The side-effects and added benefits are really cool and I’d like to walk you through all of them.

Freescale MKL17Z256VFM4: The New Bootloader

We’ve changed our secondary MCU from a Nuvoton Mini54TAN to a Freescale MKL17Z256VFM4. The purpose of the chip was to act as a bootloader to the main MCU and contains the code to load firmware through the USB connector.

One major benefit is that it allows your code to take up the whole MCU without having to worry about the two different firmwares interfering with each other. This is the same as a software program keeping functions in two different classes. What this means (practically) is that you can set up a hardware timer or interrupt and not have to worry that it will interfere with your cellular data.

More Simplicity In M2M Communication And Firmware Updates

We’ve changed the order of the chip to place it in-between the main MCU and the cellular modem. This is big. Instead of providing libraries that you compile and then place on your MCU, the cellular communication libraries and over the air updates (OTA) all live on the secondary MCU. We’ve dramatically simplified the complexity needed to talk to the cellular device and now you don’t have to download the code every time you change your firmware. If you’re using OTA updates, this means you use less data to update your firmware, allowing you to be more flexible. We’ve also added flash to store firmware. This means you can store versions of the firmware and switch back to them without having to re-download them. If you need to install a debug update, you can revert back to the main firmware without paying for it twice!

Flexible, Harder to Brick And, Well, Awesome

Another reason this helps you is that the primary MCU is now more flexible. If you use our files to make your own hardware, you can change the MCU to one of your choosing and only need to change the serial drivers. The data is still the same, no matter what device you use.

The final thing that helps you out is that this makes the device much harder to brick. By having a secondary MCU that takes care of bootloading, you can write the most abusive code and we’d still be able to reset the main MCU and reprogram new code. If you’ve ever written an infinite loop with all interrupts turned off and no access to reset, you’ll know what I’m talking about.

Schedule Update

The updates that we’ve made have pushed back the schedule. We think that these changes are worth the extra development time. Although we’re making another round of prototypes, we think that the reduction in OTA data and simplification of the API are big, big wins. The very nature of crowdfunding means that we get to listen to your wants and needs and make balanced tradeoffs in the design.

We’ve submitted our BOM for procurement so the parts will be ready for our pilot build. We’re still planning to have the parts ready for an August build, but we think this will get pushed back to September in order to debug the new changes in the board and to make sure the new bootloader is tight. The last thing we would want is to ship hardware that can’t reliably be updated remotely, so we will be doing our diligence and testing the new firmware.

We’re in the middle of a closed Alpha and all of the performance and feedback has been great. Watching someone get a cellular “Hello World” app up and running in minutes without special libraries has been really gratifying. I can’t wait to see how you all change the world once you get these boards in your hands.

If you’re interested in participating in our beta, we will be shipping out units in the late June early July time frame.

Have questions or feedback?

Let’s talk! Use this thread to let us know what’s on your mind.


#2

Is it possible to operate M1 while M2 and the cellular modem are powered off or in a low power state? My applications have very intermittent need for a cellular connection.


#3

Thanks for your question! Yes, it is possible to run M1 (the microcontroller responsible for running your own user programs) while M2 and the cellular modem (collectively, the cellular stack) are in a low-power state.

More technical insight: Our cellular stack (M2 and the cellular modem) are being programmed to enter a low-power state when no data is being received from M1. Several configurable variables, like cellular timeout, will be exposed to the user for application-specific tweaking. M2 will have its own timers set to wake at regular intervals, so that it can take control in the event the user program on M1 fails and M1 needs resetting and/or reflashing; however, it will also be possible to configure M2’s timer intervals so that it doesn’t wake excessively. These values will be configurable both via our API/website and from M1 using an optional library.


#4

I have read the “How can I power the Dash / Dash Pro” in the Kickstarter FAQs and I was trying determine if there was another way to charge a LiPo battery without using the battery connector. I want to charge the battery when I use the USB but having to connect a battery to the current battery connector location does not work with my enclosure idea. Is this possible? If not any way to move the battery connector or a add a way to tap into the battery connector circuit??


#5

Thank you for the question Moyerek. The VBatt and VUSB both have pinouts on the standard connectors. You can connect to the battery, the USB power, or both.


#6

Thank you for the information.


#7

Updated Dash and Dash Pro pinouts: https://konekt.io/blog/updated-pinouts-for-the-konekt-dash-and-dash-pro/


#8