.the hid.device open error can happen when trying to upload to Dash that is not in Program mode.
Following the information from Pat Wilbur above allows uploading without the error.
Thank you for the help guys.
I followed pmjacksonās instructions (uninstalled python 3.4 and installed 2.7, hidapi-0.7.99-6, have my Arduino folder as C:/Arduino) and Patās note about powercycling and uploading within 10 seconds but I am still getting the same error message as before:
Traceback (most recent call last):
File "C:\Arduino\hardware\konekt.io\dash/tools/update_dash.py", line 63, in <module>
update(args.path)
File "C:\Arduino\hardware\konekt.io\dash/tools/update_dash.py", line 34, in update
h.open(vid, pid)
File "hid.pyx", line 48, in hid.device.open (hid.c:1281)
IOError: open failed
At this point, I suspect itās a communication issue. What happens on your Windows machines when you plug in your Dash? Does it mount as an HID, COM, etc or show up anywhere in Device Manager? Do you get any errors?
Mine currently displays in Device Manager, briefly, with a device status of:
Windows has stopped this device because it has reported problems. (Code 43)
A request for the USB device descriptor failed.
Then disappears on its own a few seconds later with the error:
Currently, this hardware device is not connected to the computer. (Code 45)
To fix this problem, reconnect this hardware device to the computer.
A request for the USB device descriptor failed.So that looks like a problem with the hardware. I think mine just mounts as a generic HID hardware device. It doesnāt give any errors like that. (Unfortunately, I donāt have the board in front of me to grab a screenshot and wonāt have it until Wednesday)
Youāre using a regular Dash, right? I wonder if something is wrong with it. I think we still owe you a couple which should be shipping very soon. If those work and this doesnāt then weāll send you out a replacement.
Hey guys, just wanted to let you know that we fixed that issue with the spaces on Windows. The latest revision in the repo should now work with the default Arduino install directory.
Iāve got a Dash Beta, activated the SIM, attached antenna, and powered via 5v on 5VIN and GND pins. The lights come on and blink. I can then see āunknown deviceā on the konekt.io dashboard. Then I try connecting the USB to a linux system, but no device shows up under Linux (typically to do serial on a USB, some standard serial emulation like FTDI, PL203, etc has to be known and this enables communication on say /dev/ttyUSB0 or /dev/ACM0, even for Arduino). Alternatively I could try using TX and RX and a spare FTDI converter, but which pins on the Dash Beta? I noticed elsewhere there is a pinout document, but there are three UARTS and I donāt know which to try.
Try pushing the PGM button. On the dash, itās the one closest to the battery connector.
Hooking up a 3.3V TTL/UART to serial convertor is a great way to do debugging. Here are some pinout diagrams for that:
@pmjackson Are you able to put a current meter or a scope on the power in to see what kind of current is being drawn at rest, during transmission, or whatever you encounter?
Hello Rubenk,
Using a Digital Meter and canāt really see fast current pulsesā
Not sending ā about 90ma
While Sending ---- 250ma
Anyway, I am able to use a USB cable to fully power a DashPro.
But, I have good cellular signal strength.
1 Like
OK Reuben, I put an FTDI chip on the pins you suggested, then ran miniterm.py -b 9600 /dev/ttyUSB0, here is the output:
Ā„Ā¹ĀĀmodem bootstrap process...
DEBUG: Boostrapping (1/14): Init modem (can sometimes take several minutes).
DEBUG: Boostrapping (2/14): Init event handling.
DEBUG: Boostrapping (3/14): Config modem.
DEBUG: Boostrapping (4/14): Init SIM card.
DEBUG: IMSI loaded:
DEBUG: 234507093103515
DEBUG: ICCID loaded:
DEBUG: 8944501003151035150
DEBUG: IMEI loaded:
DEBUG: 358683063116207
DEBUG: Boostrapping (5/14): Locate carrier signal.
DEBUG: Boostrapping (6/14): Establish operator link.
DEBUG: Boostrapping (7/14): Config network.
DEBUG: Boostrapping (8/14): Config APN.
DEBUG: Boostrapping (9/14): Config IP address.
DEBUG: Boostrapping (10/14): Link up (1 of 2).
DEBUG: Boostrapping (11/14): Link up (2 of 2).
DEBUG: +CME ERROR: PDP authentication failure
+EVENT:LOG,48,4,CRIT,38,+CME ERROR: PDP authentication failure
DEBUG: Boostrapping (12/14): Link verification (1 of 2).
DEBUG: Boostrapping (13/14): Link verification (2 of 2).
DEBUG: Boostrapping (14/14): Enter serial passthrough mode. OK
+++
DEBUG: Pushing data to cloud
DEBUG: Data sent to cloud successfully
So it looks like this may have worked (though because echo is not enabled, you donāt see anything above). But when I visit apn.konnect.io, I just get redirected to the dashboard. Should I be able to see what I pushed? What about those PDP auth errors, are they normal?
I think seeing those errors occasionally is normal. It just means the signal might have dropped out on the first attempt to connect but it did eventually work.
To see your data, just login to the dashboard and click on āTopicsā
Hi Reuben,
Iām not seeing anything (that looks familiar) on the dashboard/topics. What I see is just a JSON string,
{
"received": "2015-09-24T13:03:10.041298",
"authtype": "otp",
"tags": [
"_SOCKETAPI_",
"_SIMPLESTRING_"
],
"routingResults": {
"matchedRules": 0,
"errors": []
},
"device_name": "Unnamed Device (35150)",
"errorcode": 0,
"source": "8944501003151035150",
"timestamp": "188",
"data": "",
"device_id": 350
}
I would have expected to see ādataā:āwhatever it is that I typedā in there, but thereās nothing. Is there a way to turn echo on? Or is there some special syntax for the data before I hit Enter (ie before newline on the serial line, is there some convention)?
Ted.
Weāre currently working on a firmware bug that is sporadically causing the first message after boot-up to get sent as a blank message. Try sending a second message and see if that shows up.
Also, I donāt think our firmware supports echo right now, but if you turn local echo on in your terminal then youāll be able to see what youāre typing
Hey Reuben,
I have noticed the first blank message.
Questionā¦Will the Beta devices firmware be able to be updated?
Yep, weāll let you know soon how that procedure will work.
Iāve had some success pushing bytes to the cloud. Now Iām thinking how to engineer the particular application need I have. Iāll have the Dash Pro Beta communicate, through an Intel Galileo and BLE dongle, to a sensor device manufactured by a well-known āUnicornā company. This device has to report sensor values and get information back, through an HTTP conversation, to their database. Doing this in real time safely records sensor values and resets them for continued sensing. The interaction is encrypted and BASE64 strings, not REST or JSON. Due to the encryption, we pretty much have no choice other than to use HTTP connection to their site (nobody has been able to reverse engineer the protocol). The HTTP connection seems to have multiple messages back and forth (maybe using Connection Keep-Alive, I canāt recall the details). Bottom line? Iād like to move from the basic Konekt tutorials of serial write, on to actually using HTTP to an external URL on the Dash Pro Beta.
I suspect that to do this, I may need to program in C using Kinetis Design Studio or similar. Perhaps using the program button and the USB it will be possible to upload new code in the Dash Pro Beta. However, I have no idea about what kind of stack there is for HTTP and how it would work. So far, Iāve not seen anything about this in the documentation. Can you point me in the right direction?
Ted.
Hello Ted,
For clarity for everyone reading this thread, the Dash and Dash Pro can be programmed with either the Arduino IDE (instructions here) or Kinetis Design Studio.
Option A (might work): In a future version of our Dash and Dash Pro firmware, it will be possible to perform HTTP communications directly to a server of your choosing. It might be tricky to work with a Connection Keep-Alive scenario, thoughāweāll have to think through that one!
Option B (would likely work): it might be possible for you to implement a web relay service around our platform to do what you need, where your web relay service would be keep-aliveāfriendly. We just launched the Konekt Tunnel Service for inbound data to devices, and will soon be launching a REST API method in the Konekt Cloud for sending inbound serial data to/through the Dash as well (the REST API method wonāt need to use the Tunnel Service).
With this option, the theory of operation would be:
DEVICE (SERIAL) --> KONEKT DASH --> KONEKT CLOUD --> YOUR RELAY SERVICE --> THIRD-PARTY SERVER (HTTP)
and:
THIRD-PARTY SERVER (HTTP) --> YOUR RELAY SERVICE --> KONEKT CLOUD (or Tunnel) --> DASH --> DEVICE (SERIAL)
Your relay service would be able to maintain communications with the third-party server over a Connection Keep-Alive HTTP session, and you could use either the Konekt Cloud REST API method or the Konekt Tunnel Service as a means to send inbound serial data to/through the Dash or Dash Pro.
Effectively, this would be using a Dash or Dash Pro as a hardware-version of the Linux/Unix netcat tool.
Now that Iām able to communicate with the Dash board and send messages to the cloud (Iām also experiencing the blank data messages but hopefully that bug gets resolved soon), I would like to port over some functionality from a device built using a Teensy 3.1. How do I enable the following:
- Power savings - My device is inactive most of the time and should be switched to a low power state when not in use. I was using the popular Snooze library on the Teensy. The kickstarter page mentions some sleep/wake optimizations
- Charging - Do the beta Dash units have a functioning battery manager and how do we go about using it? Other forum posts seem to indicate that the boards cannot be run off both USB and battery so itās not clear how to charge them
- Clock - Does the Dash have a RTC? How is it set/powered?
- OTA Firmware updates - Is this feature included on the Beta Dashes?
PS: Helpful hint if youāre experiencing similar errors as I was (Computer recognizes something was plugged in but does not recognize/mount/install Dash): check to see that your computer is providing sufficient power through USB. Mine was not but one I plugged the Dash in through a powered USB hub, it worked! --debugging courtesy of Ruben
Just wanted to say that I got everything up and running. Windows 10; Python 2.7 (actually using a version that installed with my ArcGIS software), already in path, scripts added to path; installed pip, installed additional py software from repo using pip; didnāt worry about version control of hidapi; moved Arduino directory to C:\ (apparently unnecessary now); pushed the little button nearest the ublox module on the dash pro, compiled and uploaded. Didnāt activate my cellular module but hey, no errors.
Is there no way to get a serial monitor with the dash through the USB cable? I donāt have an FTDI converter laying around.
Are there plans to add this in the future?
Hello @canmobilities,
The occasional blank cloud message bug should be resolved in the next firmware release (along with an easy-to-use firmware updater client!)
Thank you for the questions you asked. Here are responses, in order:
- Power savings - We are working to release sleep/low-power modes with our production firmware shipment this month. The Snooze library on the Teensy is fantastic, and weāll try to make our implementation as similar as possible.
- Charging - Iām going to ask @DazzlingDuke to chime in on this one, because Iām focusing mostly on firmware.
- Clock - Yes, the Dash has more RTCs than we even know what to use them for! As the Dash associates with the cellular network, network time is provided to the modem during the association (and in a handshake that doesnāt consume any of the deviceās data plan). We are working on syncing the RTC with this time. As RTC is useful in both power saving implementations and proper crypto implementation, this is a dependency of some of the other features that are planned in our stock firmware. You will be able to set/read this value in a similar fashion as on a Teensy using their Time abstraction methods.
- OTA Firmware updates - The firmware that shipped with Beta dev kits does not yet support OTA updates; however, I can say that, over this past weekend, we made significant progress on implementing OTA updates for both underlying system firmware AND user programs. We plan to release a firmware update for the Beta dev kits to add OTA update support when we ship the rest of the dev kits this month.
Thanks,
Pat
1 Like