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.
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#.
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.
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.
Does anybody know any online tutorials about receiving data between a desktop client (in c# mostly) and an iPhone with bluetooth?
How would a C# desktop client connect over bluetooth... by reading the COM Ports?
From what I understand the iPhone will not pair with a PC as a bluetooth device, as an iPhone will only connect to approved device types. There may be some way to "fake" this and have the PC show up as an approved device, though I'm not sure there's a BT stack to do this.
An easier solution (if it meets your requirements) may be to try using the WIFI connection, you can open up a TCP socket between the device and PC fairly easily and push data through it at a high rate. You should be able to do this with an ad-hoc connection (so you don't need a router) though I've never tried it. You might want to look into cocoaasyncsocket if you do this.
I am trying to develop the application which, any mobile is connected with PC and needs to send SMS through the mobile one by one, software is used only to connect the mobile and type the message.
When the send button is clicked the message should send through mobile not through any modems.
I have tried to search everywhere, but I couldn't find anything.
Can anybody guide me on how to proceed?
Thanks in advance.
If you want to do it on your own without using a sms-library you can open the modem in handset through a serial port and send out hayes at-commands for sms-operation.
Before you program you can try it using a terminal program.
Example
; Send message to "0170 00000" (Ctrl+Z to finish and send the message)
AT+CMGS="017000000"
> This is a SMS Test!!^Z
+CMGS: 3 ; OK, message gone
Note: these at-commands are not supported on every handset. Maybe the handset needs additional configuration through extra at commands (set textmode, set sms-gateway, ...)
Several sms hayes related commands are described in http://www.cellular.co.za/at_etsi.htm .
Yes, absolutely you can send sms through your pc connected with your cell phones. "Nokia PC Suite" is the only software; after installing software in your computer, connect your Nokia handset by usb cable with computer and select pc suite option. After then launch Nokia PC Suite. Now there u go.
What you are trying to do is difficult. It is difficult not because the programming is difficult, but because there are restrictions (security!) from the carrier side and from the mobile manufacturer side.
To be able to send messages from a mobile device connected to a PC, the mobile device must provide access to the internal functions its OS uses to deliver those SMSs. They could be low level modem commands, or a high level API; but in any case it will depend on the device manufacturer SDK.
If you want to type more efficiently, then maybe a mobile device with support for a bluetooth keyboard is a good idea.
I guess that depends strongly on the used mobile phone. I don't think there's a generic solution for all manufacturers. And such feature is probably hardly documented.
However, I'm not sure, if this is worth the effort at all, because e.g. Nokia provides the software "Ovi Suite" (or older PC Suite), which already supports sending SMS via connected phone. I think there are similar programs from other manufacturers.
It is possible to send SMS from a computer via a connected phone, but the phone itself will be the modem (I assume you don't want to connect another device for SMS). You can see this question, this question and (possibly) GSMComm for more info