For my senior design project, we have developed a Windows Store App to control a 2-player tug-of-war style game (all in software) which is controlled by the energy levels of each players EEG signals (specifically alpha/beta bands, relating to concentration levels) which we are transmitting over Bluetooth LE. We are also thinking about controlling a physical component to the game with an STM32F0 Microcontroller.
Basically, every so often (on some event trigger) we want to send a value between -100 and 100 in 2's complement to the uC to control the direction that the motor will move and it's speed. All the research I have done has suggested that Windows Store Apps do not support serial communication at all, but I was hoping there was a not-too-difficult workaround. We have a USB to serial adapter which will be able to communicate with the uC's UART. Is it possible to use something like Tera Term, where the Store app could communicate with the terminal upon some event and send the data over the serial port? Could the Windows App open tera term and write values to it? The communication need only be in one direction.
I'm open to suggestions on alternatives (aside from writing some custom driver, which would be too complicated for the amount of time that we have remaining to finish the project). Should we just completely abandon the prospect of serial communication and look into something like zigbee or bluetooth? I know it's possible to communicate over serial port using System.IO.Ports in a WPF/Windows Forms application but that is not an option at this point, since we have already developed the entirety of the host application (minus this serial comm). Thanks!!
EDIT 1: I'm considering using a UDP socket as a means of sending the necessary data to a background Windows Forms App which should be able to communicate over a serial port.
I don't think that network access to localhost is allowed with store deployed windows store apps. However Bluetooth serial port profile may be a possibility, judging by a quick google revealing this.
However, given that WPF has access to a rich library of IO communications support, and it is mostly a superset of WinRT, a port may be easier than you think.
Related
I want to make a simple desktop app that receives data from my phone and does certain stuff accordingly. I don't need to send any more than 1 byte. I tried UDP but it requires firewall bypassing which is a spooky popup to click on. I also tried Bluetooth but I couldn't get it to work because most of the documentation is about BLE not Bluetooth Classic. Is there any other way I can communicate with another device from a short distance even if I'm just limited to sending 1 byte? I would like topics to research but code samples are also welcome, preferably in C#.
Good afternoon, I'm developing a system with a pair of Hololensv2 and an android smartphone using Unity.
In my system the smartphone should send some data to the hololens, more precisely I'm trying to send the location data (GPS) cause in the hololens there's not that specific sensor.
I developed a full functioning UDP solution already, but now I need to build a network free one to be able to use everything outdoor.
The first possibility that came to my mind was to use Bluetooth, connect the 2 devices a send from the smartphone a message to the hololens.
Following this project on GitHub: https://github.com/FlipWebApps/HololensGPS i managed to build a theoretically working Bluetooth receiver on the headset, the problem is that it is a beacon receiver and not all the smartphone can be set as beacons.
Moreover, on Unity, I can't use directly Bluetooth directives but I need to pass through a plugin. I tried 2 already without good results:
https://assetstore.unity.com/packages/tools/integration/ibeacon-15260
https://assetstore.unity.com/packages/tools/network/bluetooth-networking-for-ios-tvos-and-android-124274
While with the first one I didn't get anywhere, with the second one I managed to find, without being able to connect to it, the hololens Bluetooth.
I really feel like I'm missing something...
I don't even know which option would be better between trying to connect the 2 devices directly or to keep trying to set the smartphone as a beacon and the hololens as a receiver...
Any idea/suggestion would be highly appreciated... Thank you all.
It really depends on the type of communication needed across devices, but since your networked version is UDP a one-way broadcast should work. If the Android device is broadcasting a value then the Hololens can just listen, and it should not matter if you have 2 or 200 of them. The trick is that none are 'connected' to the broadcaster, they are just observing.
You would only need to connect the two Hololenses to each other if they provide dependent services. In that case you might consider setting the Android as a WiFi host which would have greater range and is already coded ;)
If there is no need for that level of range or complexity, the Beacon protocol can act like UDP. As Beacons are Bluetooth Low Energy (BLE) you would need to set the Hololens to Observer mode so that it will listen but not connect. A very good explanation on how to do that with BLE on a Pi is here.
I was in the same situation as you, and I solved it using UDP. You need to have two phones, however, since Android phones (and I imagine iOS devices as well) do not make themselves a part of their own WiFi hotspot for security reasons. You have one phone acting as the switch, with its WiFi hotspot enabled. Your second phone connects to that hotspot, and broadcasts its GPS location over UDP. Your Hololens also connects to the same hotspot, and can then receive the UDP messages. All using Unity code, without the need for native Bluetooth plugins.
Below I have included information about the specific microcontroller and library I am using for the microcontroller only to provide a little context and in case someone has experience with them. I am really looking for some broad answers about USB bulk communication vs other USB styles of communication.
I am developing a UWP based app to communicate with a TI TM4C based microcontroller. The microcontroller has several analog and digital sensors which need to be transmitted and logged/displayed in the application.
I would like to use the WinUSB.sys driver for USB communication with the device because I have read about a lot of problems with the usbser.sys driver and I want to avoid using System.IO.Ports namespace because of well documented issues with event reliability. The WinUSB driver would allow me to use the Windows.Devices.USB namespace instead.
The communication structure I am envisioning between the application and the device would be simple requests for data from the application and the device sending the contents of its data registers (<50 bytes). Other commands from the application would set certain output values manually and would anticipate an acknowledgement from the device that this was done successfully or any error that occurred.
TI provides a bundled library for the microcontroller called TivaWare USB Library
1) Does anyone foresee any issues using bulk transfers for communication between the application and the device? Particularly, I was concerned with this description of bulk transfer found in the Windows Documentation "Therefore, when the bus is busy with other transfers, bulk data can wait indefinitely."
2) Bulk transfer is described as having error detection and retries baked in. Does this mean using other methods I would need to implement some kind of error detection for data transmitted like a CRC?
3) This page describing using WinUSB with UWP apps seems to imply that the WinUSB driver can be used with a CDC device class, does this mean that I can communicate with a CDC class device with the Windows.Devices.USB namespace or am I still stuck using System.IO.Ports since CDC devices expose virtual com ports? (At least when using the USBser.sys driver. Does it work the same with the WinUSB driver?)
We ended up using the TivaWare library keyboard example to help us build our own HID device and write custom HID report descriptors. C# UWP does indeed have excellent support for HID devices and we used the humaninterfacedevice library. The TivaWare library is difficult to work with if anyone is considering going down the same path.
I haven't been able to find any resources regarding this, so I thought I'd ask here.
I have an iOS app that I am developing, as well as a C# desktop app. I'm currently able to connect the two by creating a Socket Server on the desktop app, and connecting from the iOS app. This works well, but I'd like to do this without requiring the devices being on the same network. Communicating via Usb (lightning port) seems like the logical choice, but I can't find any resources at all about how to do this. Are there any tools or best practices regarding this, or is this even possible?
Thanks!
Peertalk, an open source library allowing to pass TCP connections through the USB connection without being part of the MFI program. PeerTalk uses the iTunes usbmux system to relay TCP connections across the iOS USB connection.
I wasn't able to use Peertalk, since I'm using Xamarin for my project. However, I spent the last week researching and documenting what I learned, and I posted it as a blog post here
http://thecodewash.blogspot.com/2017/05/communicating-with-your-ios-app-over.html
Hopefully this helps others.
I am working on driver that talks to a device via a serial port in C#.
I do not always have the device available to do physical testing with. Is there a way I can simulate a device on a serial port so that it responds in an ideal manner?
Get a second COM port and use a Null-modem cable to connect the COM ports to allow two C# programs to talk to each other.
I used Com0Com for a while and wrote some simulator/emulator code.
What kind of driver? If it is the serial interface driver, then that gets quite tricky.
However, if your driver is an application level above the Windows device driver, then it's fairly easy to replace the i/o behavior by altering the string passed to CreateFile, or whatever layer on top of that C# uses.
== More ==
Since you use the .net library tools, this technique may be too yucky to bother. However the idea is to replace where, at some point, your code says open COM1: or whatever. Change that to be a file which has the simulated data, say `c:/com1testdata.txt'. Additional emulation code which recognizes the contents of the file for pauses and/or responses might be useful for some protocols. Data which is written to the port can be logged or ignored, depending on your requirements.
When working in a team designing some custom hardware I used a great terminal emulator called ZTerm (only available for Mac, I believe). It allows you to script responsees which enabled me to complete the software to our pre-agreed specification while the custom controller chips were still in the design iteration stage.
If you're running in a VM, you may be able to attach things to the serial port. QEMU, for instance, allows you to attach the virtual serial port to a TTY, which you can then interact with either manually or with a program running on the host.