Teensy positioning w.r.t. Windows 10 Internet Of Things

Status
Not open for further replies.
S

stevech

Well-known member
A very odd set of bedfellows... see PDF enclosure. maybe this is a parade one can watch from afar?

"... first Arduino certified OS"... hmm... did they find someone to sign the certificate?

Curious to see how much time and effort MS is putting into IoT with the Windows 10 core OS (no UI). All told, it's probably less money than the printer paper budget at MS.
But, we read that Windows XP embedded got into a zillion ATMs. Wondering where a heavyweight Win 10 IoT makes sense in IoT devices.

View attachment Arduino-Win10-IoT.pdf

edit: Added this link
https://dev.windows.com/en-us/iot
 
Last edited:
Arduino-certified operative system. After the TISS (typical-italian-shit-style) diatribe about arduino.org and arduino.whatever this looks quite bizarre to me :cool:
(sorry, can't resist to celebrate my 200nd post with TISS)
 
I'm failing to see the benefit of a clunky degree of separation from the hardware, on embedded devices?

If I wanted an OS, I would not be using an arduino.

The cynic in me wonders how these little atmel chips really will respond to the Microsoft bloat-factory codebase.
 
Quick addendum:

Windows Virtual Shields for Arduino
Windows Virtual Shields for Arduino is an open-source library primarily for the Arduino UNO which communicates with an open-source Universal Windows application running on all Windows 10 devices, including Windows Lumia phones. The library exposes Lumia phones' sensors and capabilities to the an Arduino Wiring Sketch.
Click to expand...

It appears to be a Lumia app, which connects to an arduino Uno via bluetooth and sends the sensor information through.

It has potential. If it worked on Android and iOS too.

But any "standard" for Internet of Things has to work with all "Things", on principle.

If it is not a universal standard then it will not take hold.

We need an Arduino bluetooth IoT standard protocol with discoverable "entities" such as "Screen" or "accelerometer" which expose Points (in bacnet terms, these are groups of values which may be read only, write only, bidirectional etc.).

But they must be discoverable, by a search, and universal. This is the only way IoT will ever mean something.



Before uploading, temporarily remove the Bluetooth TX and RX wires from the Arduino. (There is only one serial port shared between the USB and Bluetooth. The Bluetooth interferes with the upload).
Click to expand...

Ouch.
 
Last edited:
curiouser and curiouser:

Windows Remote Arduino uses the Firmata protocol, which has implementations in many languages including Arduino. The Arduino implementation is called StandardFirmata and comes pre-packaged with the Arduino software when you install it. Follow the steps below to upload the StandardFirmata sketch to your Arduino.
Click to expand...

That's a little more like it.

Firmata Protocol Documentation
Firmata is a protocol for communicating with microcontrollers from software on a computer (or smartphone/tablet, etc). The protocol can be implemented in firmware on any microcontroller architecture as well as software on any computer software package (see list of client libraries below).

Firmata is based on the midi message format in that commands bytes are 8 bits and data bytes are 7 bits. For example the midi Channel Pressure (Command: 0xD0) message is 2 bytes long, in Firmata the Command 0xD0 is used to enable reporting for a digital port (collection of 8 pins). Both the midi and Firmata versions are 2 bytes long, but the meaning is obviously different. In Firmata, the number of bytes in a message must conform with the corresponding midi message. Midi System Exclusive (Sysex) messages however, can be any length and are therefore used most prominently throughout the Firmata protocol.

This repository contains documentation of the Firmata protocol. The core of the protocol is described in the protocol.md file file. Feature-specific documentation is described in individual markdown files (i2c.md, stepper.md, servos.md, etc). Files appended with '-proposal' are proposals for new features that have not yet been finalized.

The Firmata protocol could theoretically be implemented for any microcontroller platform. Currently however, the most complete implementation is for Arduino (including Arduino-compatible microcontrollers). Here are the known Firmata microcontroller platform implementations:

Firmata for Arduino
Firmata for Spark.io
Please note: I'm sure there are other implementations. If you know of others, please submit a pull request to update this readme file, or open an issue providing the link to be added to this document.

Firmata client libraries

There are several client libraries. These are libraries that implement the Firmata protocol in order to communicate (from a computer, smartphone or tablet for example) with Firmata firmware running on a microcontroller platform. The following is a list of Firmata client library implementations:

procesing
[https://github.com/firmata/processing]
[http://funnel.cc]
python
[https://github.com/firmata/pyduino]
[https://github.com/lupeke/python-firmata]
[https://github.com/tino/pyFirmata]
[https://github.com/MrYsLab/PyMata]
perl
[https://github.com/ntruchsess/perl-firmata]
[https://github.com/rcaputo/rx-firmata]
ruby
[https://github.com/hardbap/firmata]
[https://github.com/PlasticLizard/rufinol]
[http://funnel.cc]
clojure
[https://github.com/nakkaya/clodiuno]
[https://github.com/peterschwarz/clj-firmata]
javascript
[https://github.com/jgautier/firmata]
[http://breakoutjs.com]
[https://github.com/rwldrn/johnny-five]
java
[https://github.com/4ntoine/Firmata]
[https://github.com/shigeodayo/Javarduino]
[https://github.com/kurbatov/firmata4j]
.NET
[https://github.com/SolidSoils/Arduino]
[http://www.imagitronics.org/projects/firmatanet/]
Flash/AS3
[http://funnel.cc]
[http://code.google.com/p/as3glue/]
PHP
[https://bitbucket.org/ThomasWeinert/carica-firmata]
[https://github.com/oasynnoum/phpmake_firmata]
Haskell
[http://hackage.haskell.org/package/hArduino]
iOS
[https://github.com/jacobrosenthal/iosfirmata]
Dart
[https://github.com/nfrancois/firmata]
Click to expand...

Too low level though.

Every solution will be custom.

What you want is a touchscreen in your hallway (or hand!!) that can auto connect with every camera in the house, every audio playback device, every light switch, every kettle, every temperature sensor, every valve, every heating controller, every AC unit, via a discovery feature.

And this connection needs to be medium-agnostic, i.e. bluetooth,WiFi, 868Mhz, visible light etc.

We are a long way off.
 
Last edited:
seems it's all heading towards $2-4 WiFi modules like the ESP8266 and better. Connected to lights, sensors, etc. The access point would be an Android tablet in the wall, plus your smart phone.
Homeseer dot com was among the early providers, adding a small form factor PC at first, then a rebranded/reprogrammed RPi.

I'm in the crowd of life-long BSR/X10 uses, lights and outdoor fountain water pumps. I never went to Z-Wave or (better), Insteon. Nor ZigBee. X10 is just good enough, with Homeseer running it, and even that is an overkill! But with the near-demise of X10, the module prices are way up, but still well below the too-high cost of Insteon modules. For me, anyway.
 
Well I remember back in the day, when I bought some X10's to control some embedded boards I was doing GCC ports for that the X10 website was so overwrought with blinkies and flashing lights and ads, that it was impossible to navigate, and back then I didn't create a separate email address for each company I dealt with, that de-spamming my inbox was a recurring problem.
 
Wireless is nice(feels good to be bathed in RF). TCP/IP connectivity can be nice.

Starting with an 8032 clone, have used simple RS485 current loop with some form of slave/master protocols for last 20 years of home projects. Am now a style'n dude with a fancy-pants SAM4 controller - but still use good old current loops. When we move next year will have to decide if am gonna just put it all on CAT6. Am thinking about distributed control with several T-LC modules.
 
So far, it seems "Arduino Certified" means nothing more than a large corporation was willing to pay a license fee. There doesn't seem to be any quality control or approval process to prevent mostly incompatible, poorly designed products like Intel Galileo from eroding trust in the "Arduino Certified" name.

Maybe this Microsoft thing will be awesome, but I'm skeptical...
 
Pensive said:
Quick addendum:
It appears to be a Lumia app, which connects to an arduino Uno via bluetooth and sends the sensor information through.
Click to expand...

One summary item along with this was: 'Your Nokia phone has $200 worth of sensors in it'
> which is true - but how are they exposing it? And will it map to other phones?

... MSFT things caught my eye - but nothing earth shattering when I scan the links. Watched the HOLO robot example that was great fluff - as long as you had on the 3D headset - I kept wondering what the audience was seeing as she talked to a pair of wheels without the virtiual Robot Top and HUD? Also they changed the lights to purple - except the Red/Green Wheeled base lights stayed R&G when she excitedly showed the HUD update the HOLO_BOT top change to purple?

They are putting CORTANA on everything - they've put OFFICE on Android/Ios before having a touch screen desktop version, but maybe this 'sensor pack' connector will map to other phone types - I can't find the link again now.

I keep an encrypted XL file of passwords on my OneDrive - I can open that with the other two 'generic OFFICE' apps on my Android - but when I use the MSFT XL app to this day it says 'file cannot be downloaded', and if I recall that was the same on the Nokia's I last tried as well.

EDIT:: Just recalled I have 3 Windows Phones all were about $50 (one was a free trade for an old original DROID) - not sure which are up to the spec needed for a $200 sensor set for Nokia.
 
Last edited:
BJB said:
Wireless is nice(feels good to be bathed in RF). TCP/IP connectivity can be nice.
Click to expand...
While I think modules like the ESP8266 are the way forward cost wise, it's important to note that these modules, and TCP/IP communication based modules in general, have a disadvantage when it comes to power. TCP/IP actually has an architectural disadvantage because of the handshaking involved and the lack of a specific sleep state. Add a physical interface like 802.11, which often suffers from interference in the ISM band, or, even worse, the power hungy Ethernet and you will run into big trouble for IoT applications that need to run of a coin cell for years or use some form of energy harvesting. And those things will form a big chunk of the IoT.
 
Not certain about energy efficiency for IOT stuff - as none of the usual suspects (NRCan, DoE, CEC, ErP) have directly addressed or attempted to define the scope of this class of equipment. But but the CEC/DoE will indirectly control this via the appliance and HVAC efficiency regulations.

For EMI, you EU folks will see this addressed per port test methods in the new CISPR32, RED, and ETSI stuff. But dunno when these new EMC test methods will find their way into FCC regs. Canada has published an intent to update ICESS stuff to new EMC standards, so there may be short-term problems with ISM, but not in medical because of the new stuff in latest IEC60601-1-2.

That is, many ISM problems will be addressed via immunity, not emissions.
 
Epyon said:
While I think modules like the ESP8266 are the way forward cost wise, it's important to note that these modules, and TCP/IP communication based modules in general, have a disadvantage when it comes to power. TCP/IP actually has an architectural disadvantage because of the handshaking involved and the lack of a specific sleep state. Add a physical interface like 802.11, which often suffers from interference in the ISM band, or, even worse, the power hungy Ethernet and you will run into big trouble for IoT applications that need to run of a coin cell for years or use some form of energy harvesting. And those things will form a big chunk of the IoT.
Click to expand...

As far as wireless goes, if you want to something practical, you have to go mesh network, which means zigbee.

I struggle to get wifi in my garage, 15 feet from my house. And it drops out all the time.

What if the wifi connection dropped out at the moment the heating controller decides to turn your underfloor heating on? OK, problem is easily resolved with a kludge hack - resend on reconnect. But still, not ideal....

Zigbee is looking most likely candidate in the "real" IoT world (building controls). For example Harvard Eyenut - new(ish) lighting control system with entirely zigbee series 2 everything.

Of course its slow as hell compared to the robust wired solutions like KNX & DALI. And that's saying something. DALI is 1200bps :), KNX only 9600.
 
Wireless mesh for home automation is currently dominated by Z-wave and its partners. It's proprietary.

Zigbee with 802.15.4 is what some electrical utilities are moving to, for the wonderful future of time-of-day rate schedules and penalties if you don't agree to managed "load-shedding".
Most utilities naively let meter-makers drag them into some proprietary 900MHz (or 868 in the EU) solution from the meter vendors. That's why Zigbee and Zigbee Pro aren't dominating.
Zigbee, like Bluetooth, needs to be used with some application profile to do anything. And many of the profiles are intellectual property controlled.

Digi International and their XBees (series 1) have a good mesh protocol firrmware stack you can install (Digimesh) that's not onerous with licensing like Zigbee is, and is free. But proprietary. It has "sleeping/battery powered" routers that Zigbee Pro doesn't. (Xbee series 2 is Zigbee-only, per agreement with Ember (now SI); Series 1 are NXP/Freescale.
 
Last edited:
Interesting....

There appears to be a void between commercial and DIY/Hobby residential wireless - I believe you are speaking about residential installs. (possibly big differences across the pond too?)

I've been doing automation (lets call it controls, because "automation" is a very residential term) for 10 years professionally (mostly commercial but also high end premium residentials as well), never once come a cross a single new build spec with z-wave in it! I've read a LOT of specs.

Zigbee once, EnOCean 10 or 15 times. The rest is all wired solutions, mostly proprietary, but open standards are typically knx. (We focus on KNX - this is where my expertise and "day-job" knowledge lies)

We use EnOcean mostly where we can't run wires, it works fine but you have to get the wireless nodes in place. And the RTC's (Room Temperatures Controllers) take up to 2 minutes to fire (solar powered!). The switches feel horrible to press but they never need a battery.

Either way, this discussion should (indeed MUST) directly exclude closed source or proprietary solutions, IMHO. It will enver be an IoT with proprietary solutions square-wheeling progress.

Which really only leaves EnOcean and Zigbee (please educate me if I've missed one!).

my tuppence, from the uk, guvnor ;)
 
Last edited:
Things re likely different in the UK than here in the US.
Z-Wave is the trademark of Zensys for their patented proprietary wireless mesh in the ISM bands. They started in the US 902-928MHz ISM band and it was a long time before they had an 868MHz band product for the EU (and UK?).
Zensys licenses this to product makers - some big companies - so you may not see the Z-wave name, but I think the logo has to appear.

Insteon has a big market share in the US, such as the market size is!
Zibbee of course is like Z-Wave, an alliance's name. ZigBee Pro is what some utilities are using. And I think some Cable TV Settop box makers have it for the push cable companies are making into home secuirty/automation.

I haven't seen enOcean here in the US, other than some press releases about energy harvesting.

You probably know about these web sites

http://board.homeseer.com - long lived, small, big Z-Wave reseller, software maker of HomeSeer boxes and apps for Windows and their own spin of RPi, rebranded. Active user forum.
http://cocoontech.com/forums/
 
stevech said:
it was a long time before they had an 868MHz band product for the EU (and UK?).
Click to expand...

correct, we are 868Mhz throughout the EU as far as I know.

It's interesting how different the markets are. It's not going to be easy aligning the world to an IoT.

Baby steps, as they say.....
 
Pensive said:
As far as wireless goes, if you want to something practical, you have to go mesh network, which means zigbee.

I struggle to get wifi in my garage, 15 feet from my house. And it drops out all the time.
Click to expand...
A mesh network won't help you with these point-to-point range problems. If your wifi won't penetrate into your garage, than Zigbee won't either. You would have to place additional repeater nodes, but you can do the same thing with wifi too (but with a higher power envelope of course).

The problem with meshing is that it requires a very careful approach to timing if you want your repeater nodes (or routers in Zigbeespeak) to be able to sleep and save power. End nodes (the sensors) and routers have to wake up at the same time or you incur a power penalty when your end node has to stay awake until it detects the router. It's easier to have your router on all the time, but then it also draws power all the time.

Zigbee isn't the only serious candidate for Iot communication out there. There is also stuff like 6loWPAN, WirelesHART, Bluetooth CSR meshing etc.

stevech said:
Wireless mesh for home automation is currently dominated by Z-wave and its partners. It's proprietary.

Digi International and their XBees (series 1) have a good mesh protocol firrmware stack you can install (Digimesh) that's not onerous with licensing like Zigbee is, and is free. But proprietary. It has "sleeping/battery powered" routers that Zigbee Pro doesn't. (Xbee series 2 is Zigbee-only, per agreement with Ember (now SI); Series 1 are NXP/Freescale.
Click to expand...
I see no problems with proprietary products, as long as it has an open and well documented API and no or a straightforward licensing scheme. Like you said, the Digi International implementation of Zigbee is in a lot ways better than 'vanilla' Zigbee, it's reasonably well documented and has (afaik) no licensing schemes (it's incorporated in the module price).
There are also API's for Z-Wave available on the internet, for RPi and Arduino.
 
Digi International's Xbee S2 uses Ember's Zigbee.
Digi's Xbee S1 uses their great 802.15.4 messaging OR Digi's own "Digimesh" stack and it's better than Zigbee if not as widespread. Digi does not charge for Digimesh firmware to install on Xbee S1 via a download. I think it's widely used by their tank monitoring customers.

I think Z-wave has run its course and is fading away - due to several Fortune 1000 type companies having another fling in home automation products (like Intermec and Schlage locks) and found no market traction.

the big market, wireless meter readers, has gone to proprietary closed solutions so as to sell more of my-brand meters.
 
I see that this thread has gone cold for over two years. I am curious if someone has tried to connect a Teensy 3.2 to a Windows 10 IoT Core machine and inter-operate them. For example: exchanging data, updating firmware etc.,
 
Last I followed the links to look after the updates on the Win 10 IoT side it seemed like it had not progressed or done much as far as acceptance or broader reach.
 
I am working with a company that wants to use Win 10 IoT Core on https://keith-koep.com/en/products/products-som/myon-1-features-snapdragon-410/

That has to inter-operate with a Teensy 3.2. Microsoft says that Win 10 IoT Core supports a subset of Win32 called Universal Windows Platform (Previously called Windows Runtime (WinRT) in Windows 8). I am interested in knowing if somebody has tried to hook up a Teensy 3.2 with a board running code written for UWP.
 
Status
Not open for further replies.
Back
Top