RoadTest: Microchip AVR-IoT WG Dev Board
Evaluation Type: Workshop Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?:
What were the biggest problems encountered?: My computer died right what I inserted the device into my computer. I lost 4 versions of Windows and over 500 GB of data.
Perhaps a device like this had been released way too early without undergoing sufficient testing to assure future users their success with the operation of the device.
Sadly, I felt the device did not perform to the standard operation outlined in it's specifications which resulted in the device functioning somewhat differently other than what was specified.
While I intended to use MPLAB X along with Atmel Studio 7 to create new programs for the device, my computer died right when I plugged the device into my USB port.
With a dead computer, I lost over 500 GB in data along with 4 versions of Windows which left me struggling for an additional four hours trying to find a solution.
I ended up installing Debian Stretch with Raspberry Pi Desktop for x86 from a CD onto a 64 GB Sandisk Cruzer Fit USB Flash Drive that is working for the minute.
After careful review of the filesystem of the Curiosity drive in Linux, it was discovered that the mass storage device had a hidden Autorun file on it that ran another program that killed my computer.
It should also be noted that the device arrived with the packaging pre-opened. Someone had access to the device before it was shipped.
With that said, I would appreciate it if someone could send me another 2.5" internal SATA hard drive to replace the one that was fried by the Curiosity drive's software.
In Debian 9, the device showed up as /dev/sdb1 and was mounted successfully to folder /media/pi/CURIOSITY and showed the drive was 1.1 MB n size when I ran "df -h" in the Terminal of Debian 9. I would have at least given the Mass Storage device a 64 Mbit Flash Chip which might be possible when using the SPI Port of the device if one can reprogram the device to use a filesystem on a SPI Flash Chip over the SPI bus.
Exploring the drive further showed that it's proper contents were present along with HTML files that redirect the user to another page across the internet to see results of data being sent to a Google Cloud Sandbox account from the AVR-IoT WG Board.
Initially, the device gave continuous errors while enumerating it's red LED to indicate there was an error.
After establishing an internet connection through Debian 9, I opened the Click_Me.html file from the Curiosity drive that redirected me to another webpage across the internet to fill out a form which asked for the SSID, Password, and the encryption type for my internet modem.
It then asked me to download the form data into a configuration file that was dragged and dropped into the Curiosity drive. Sadly, it took it three times of doing that for it to register or acknowledge the file was added as it kept disappearing from the curiosity drive each time I tried to put the configuration file in the Curiosity drive.
After successfully connecting to the webpage again with the Click_Me.html file, the unit showed no errors and a blue LED came on to show WiFi data was being sent to the Google Cloud without any errors.
I was ready to create a new project at that time, but when I clicked on the Build it Now button in the Build Your Sensor Node section that was listed in the What's Next portion of the webpage in order to start a new project, I was redirected to another webpage that only offered additional downloads that were needed in order to work with the hardware. That, and the downloads were only available for Windows environments. With excitement, I was hoping to see that the ability to create projects for the device online would have been possible. I can see how a web program can let users select which sensor modules they are adding to the board from a web page, but sadly this option to program the device wirelessly this way is just not possible with the current implementation though correcting it to allow this method of programming the device wirelessly would be very easy.
An additional search using Apt-Get in Linux for MPLAB X and Atmel Studio 7 returned 0 results which left me unable to program the device as I was intending to with those two IDE's.
I did find an Arduino IDE in the repository, so if the Arduino team made their software available for Linux, it is only logical that Microchip and Atmel would follow suit doing the same.
There is a lack in the ability to program the device natively which I felt is something that should have been considered when designing the software for the Curiosity drive.
More so, I highly believe choosing the Mass Storage Class for interacting with the AVR-IoT WG Board was a bad idea and think they should have used a better alternative such as USB CDC for serial COM Port communications while creating a PC program that could control all aspects of the USB device by sending chars from the PC and using select case statements in the device firmware to select appropriate functions based on which incoming chars matched any chars in a predefined list of chars of the select case statement.
I found it trivial and pointless to redirect users to another webpage across the internet from a local HTML file. HTML files should keep the users local for their safety and retrieve data from across the internet automatically to display any results inside an iframe instead.
Another alternative could be using a PC program made with Visual Basic.net or ASP.net to send and receive data to and from the device over the internet. I would highly recommend using the USB CDC method to control all aspects of the device's hardware. At least with a PC program, users could then select which sensors are attached to the board, and then let the board do the rest of the work of providing data back to the user inside the PC program. Perhaps they could even let a user specify the frequency of the data transmission from every minute, to every second to continuous operation of the device. Controlling the device with a PC program using USB CDC is key in getting the most out of any attached hardware in my opinion and is only triggered one per button press before closing it's COM Port communication channel. This would also provide security to the end user.
At the very least, any local HTML page for the Curiosity drive should give the option to set variables for settings of the device and submit that variable data to a server which could then send results back to the end users in the very same local HTML webpage.
Additionally, I did not see a way to view individual variables so customizing usage of any incoming data is not possible. There is no way to use variable data other than viewing it in a webpage they send you to. The entire operation of the device is controlled and heavily supervised, but the concept of sending data to the Google Cloud is interesting, but I feel they should aim their focus on making byte streams available in real time. Reading variable data bytes from any device in the sandbox account as needed from the Google Cloud instead of being continuously transmitted 24/7 would make a better alternative. It would also be more secure as the device would not be on continuously and would then prolong the device's life expectancy..
In conclusion, trying to get the device up and running might take an average user around 30 minutes. Personally, I wouldn't really recommend the use of this device to others. Overall, I highly felt that sending bytes to the cloud from a device only for the same data to be returned to the very same device is pointless when users can't do anything with the incoming data in variables outside of the demo program.
Thank you for reading
I have now received my board and run it with a spare Windows 10 laptop that I can afford to loose the contents of.
Thankfully, I have not had any issues and the demo ran exactly as described in the Microchip…
Have you already tried to contact rscasny and explain about the problems you are experiencing? If not, I would suggest you do, he might be able to help you. Hope you manage to get all the issues…
We should all know by now (from general current affairs/news stories) not to plug things into the USB port without disabling autorun - and the latest versions of Windows disable it anyway (default…
Such a device may have been released far too early without sufficient testing to ensure future success for the device.
That could be, but I do not think so.
Unfortunately I had the feeling that the device is not performing the standard operation specified in its specifications, which causes the device to work differently than indicated.
While I intended to use MPLAB X with Atmel Studio 7 to create new programs for the device, my computer died instantly when I connected the device to my USB port
Here it could be that a component on the board to the USB would be defective.
This component could draw too much power for the PC-USB port and destroy its voltage regulator on the Motherboard.
Would be a pure coincidence.
On a dead computer, I lost over 500GB of data and 4 versions of Windows, so I searched for a solution for another four hours.
I finally installed Debian Stretch with Raspberry Pi Desktop for x86 from a CD on a 64GB Sandisk Cruzer Fit USB flash drive that works for the minute.
After careful examination of the file system of the Curiosity drive in Linux, it was discovered that there was a hidden autorun file on the mass storage device executing
another program that killed my computer.
It should also be noted that the device has arrived with pre-opened packaging. Someone had access to the device before shipping.
That would be in two different possibilities a Gau to a Super Gau.
1) You lose confidence in suppliers, including Newark, also Microchip as well
2) That would be really an insider, who would know the post office way to you, and exactly your transmission intercepts.
Randall sends this kit to 6 people, so we do not want to blame Randall or Newark.
This assumption is quite hhmmm ....
But yes, what I see again now, yes I am a bit lazy here:
More than ever, I'll check what's coming up and I'll check the modules before I connect them to the system.
A USB hub helps disconnect power supplies from the USB port of the PC. Such a hub I will connect from now between that ports.
I would appreciate it if someone sends me another 2.5-inch SATA hard drive to replace the hard drive fried by the Curiosity Drive software.
It seems that your PC is a laptop.
So, a laptop has more of a problem with the power supply on the USB port, which is usually designed to be weaker.
Of course this is different between the manufacturers.
Therefore, I rather think, as mentioned above, of an overload.
The overload could be e.g. certainly that a startup routine with Autorun, the transmitter output power sets to full power
and then regulates back to the entered parameters; e.g. "listening, anybody here?".
Maybe it's in this direction. So rather no intention, but rather a bad parameterization of the settings.
Maybe, I don't know because I haven't this module. It was just logical thinking about the IOT behavior.
So sorry to hear about your loss
And thank god i read all this info before using this board.
I have now received my board and run it with a spare Windows 10 laptop that I can afford to loose the contents of.
Thankfully, I have not had any issues and the demo ran exactly as described in the Microchip documentation. iexpress - I see that you have said the packaging was pre-opened?...... Although I would have thought highly unlikely, this would make me wonder if the board has been infected with a virus somewhere between leaving element14 and arriving at you. The Shamoon virus has been highlighted recently as new threat...... The symptoms sound very similar.
My package was completely sealed and as I have said I have not had any problems.
I hope you can get your PC sorted out - I think the board has a lot of potential with the right tools.
I believe the Linux version is available only via Microchip website, but I'm not sure it will work on Raspberry PI Desktop, as I only tried on a amd64 Debian 9. If it is for x86 it might still work, the only way to find out is to download and try installing. I'll be curious to know if it does work on a x86 Raspberry PI Desktop with Debian 9 though.