During the Win 3.1/95 era, we had a software plugin for our DSO-28264 that's based on Sound Blaster's Voice Blaster. The Voice Blaster gave our users ability to control the functionalities of the DSO-28264 via voice control. It worked well for those times that you need both hands to probe the DUT, but the user response were lack luster. Nowadays, being Web based, all the key components are in place for a cloud based "Ok PiMSO" control via Google's voice API.
It is a risk to tied a product's feature to others. But with the availabilty of various ARM based platforms, it is not a real concern. To date, the WebMSO solution worked on the Pogoplug, Seagate Dockstar, Beaglebone, MK802 and Raspberry Pi. The solution is flexible enough it will work on the flood of ARM based devices coming out of China. All of these devices are manufactured and sold at a price that we can only dreamed to be able to achieve. If we can't beat them with the manufacturing cost, we can leverage it to benefit our users. The end goal has always been what's best for our users.
It is true that laptop or desktop is good enough. But for the future generation of engineers that I mentored, FIRST teams, the first device that they reach for is their smart phone.
The MSO-19 and MSO-28 were designed specifically for engineering students. We balanced the feature sets to ensure that engineering students will be able to use it for embedded and FPGA designs until they finish their undergraduate studies. Having the Web based control with RPi will ensure that it is still affordable and usable on their device of choice.
Two years ago, we did not see the need for our instruments to be controllable via the web, until NASA sent a MSO-19 to the ISS to assist with their avionics upgrade. NASA was able to remotely control the MSO-19 from the ground. To date, the MSO-19 is still on active duty serving as the only oscilloscope on board the ISS. We saw the importance of remote and distibuted access instruments, hence the WebMSO project.
First, thanks for a very interesting link. My only question is why they wouldn't implement the Pi functionality internal to their system so that they are separated from Pi design changes and availability. Seems like a real risk to me.
Ideally every MSO28 should have an embedded Wi-Fi web server. But not every user needs this capability, nor do they want to pay for the added cost. This project serves to provide a low cost solution for customers that have that need.
Raspberry Pi was selected along with the MK802 for s simple fact of "final cost to the user". With the embedded Wi-Fi modules costing between $20 to $30 to OEM and the additional manufacturing cost of ARM SOC boards, it is difficult to beat the $35 RPi + RT5370USB or the MK802 with built in Wi-Fi. Both of these solutions will provide one empty USB port for the MSO-28 with the less than $50 of final cost to the user. This brings up the sad truth for small US based manufactures. Without the US distrubution channels willing to supplying the components at competitive pricing, it's is very difficult for US manufactures to compete with Chinese manufactures.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.