Microchip AVR-IoT WG Dev Board - Review

Table of contents

RoadTest: Microchip AVR-IoT WG Dev Board

Author: iexpress

Creation date:

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.

Detailed Review:

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

Anonymous
Parents
  • I lost over 500GB worth of data in a split second right after I plugged in the device.

    ...

    From my experience with it, it only works properly in Linux as it will not process that Autorun file.

    Hi Jason,

     

    You can disable Autorun on recent versions of Windows, to do this, hit the windows key and type 'Autoplay' to see the options. I believe the default on the latest Windows is to just open a Explorer window, but I'm not sure. Anyway this information is only useful if/when you've re-installed Windows.

     

    I'll update if programming the device becomes possible.

     

    Just an opinion, an opportunity is missed here despite lack of access via Windows. Maybe it would be useful to review what the device is, what processor is on-board, it's capabilities, how to use the source code and so on, even if you cannot exercise all its capabilities. As an example, here is a roadtest where none of the roadtesters had the full capabilities or equipment for a complete review, yet managed to review and document some aspects: Molex 2.4GHz / 5GHz Antenna Kit

     

    If photos/diagrams cannot be uploaded, there are third-party sites. It's not ideal, but could be a temporary solution. To report the image upload issue, click on Participate->Feedback and Support (typically a screenshot will help them, or as much detail as possible, but of course if you cannot upload a screenshot in the first place, then you may need to use a third party upload site anyway - e.g. box.com is a free option).

  • Dear Shabaz

    Yes, surely:

    You can disable Autorun

    But how could we know it was necessary, before accident?

    If the issue with modification of Windows filesystem  is general, that should be placed in the very beginning of the manual.

    In any case, I did not notice any warning or information about the necessary settings before connecting the PCB.

  • Hi Mark,

     

    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 action is to open up an Explorer window). No warning is attached to the packaging of USB memory keys from retail stores either.

      wrote:

     

    as I understood the issue, the AVR-IoT performs dangerous modifications on the disk filesystem.

    That's one way of looking at it, but it is sensible to get a second opinion, since there are several Roadtesters for this product. Surely someone can run it up with Autorun disabled, and run a virus check.. If you're uncomfortable doing that, I'm happy to do so, if someone sends me it.. it isn't a difficult thing.

  • 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.  - 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.

     

    Cheers

    ---------------------------------------

    Tony

  • , can you post the content of that AUTORUN.INF file?

  • - sure.......

     

    [autorun]

    icon=AUTORUN.ICO

     

    Files on the drive:

    image

     

    There is certainly nothing malicious on there!

     

    Also - The following shows the USB devices that show up in Device Manager for the Board:

    image

  • Hi,

     

    Yes, that's what I thought about as well.

    Usually these modules, including the software, coming clean.

    As well I never had problems.

     

    Gerald

    ---

Comment Children
No Data