Are there any good api's or examples of communicating between two devices via WiFi?
I am programming an app for 600 window's mobile (version 5) devices. They occasionally will need to connect with another device and exchange info.
Each device connects to the internet via GPRS (using the phone line). I could do the communications via that, but it is slow and may not work in all locations (this app will be used nationwide).
Just as an FYI, I also plan to look into bluetooth, but the stack we get on our Symbol Devices (MC70) is the Stonestreet One stack (we cannot change that). It is a very difficult to use stack with no managed code API. Also, it requires manual setup to use. My users will not be very technically inclined.
If there is another way to communicate (ie via the WiFi connection) I would love that.
(Ideally, I would like to be able to programmatically turn on the WiFi, send/receive data and then turn off the WiFi (to save batteries).)
Any help/suggestions are appreciated.
Motorola (who have bought Symbol a few years ago) do release an Enterprise Mobility Developer Kit for .NET CF which also has some libraries for controlling the WLAN on a Symbol MC70. I have worked with this in the past and it seems to work very well. The SDK comes with the full documentation and some sample applications.
Here is an earlier question on this subject:
better way to communicate between ad hoc wifi windows mobile devices
... which suggests that this is at least possible.
As an alternative, if the devices have infrared ports, you could have them communicate that way (I think).
Update: just found this example:
http://community.opennetcf.com/articles/cf/archive/2008/06/09/exchanging-data-using-windows-mobile-windows-communication-foundation-net-compact-framework-and-exchange-2007.aspx
It looks like you can do peer-to-peer communications with it. It requires .Net CF 3.5, however.
Someone is welcomed to prove me wrong but, as far as i know, out of the box it has to be bluetooth. WiFi is for networks. If you setup each device to also act as an access point you could make this happen. So I am sure it can be done, but it's not a clear path.
I see other issue slike security as well, because a router would handle this and now each of the 600 devices would be an access point handling this security, i am just shooting from the hip now which is basically my long winded advice to not go that direction.
-update
maybe i am a bad answerer, I just thought this was a bad direction. You can google windows mobile wifi peer to peer. Here is one site that covers it.
http://www.smartphonemag.com/cms/blogs/3/588
Related
I spent some time looking for ways to exchange data from a micro-controller Bluno Beetle from DFRobots that uses Bluetooth LE and a desktop application written in C#. DFRobots actually has a code (in Java Android), where they use GATT profiles to exchange data from/to the micro-controller and an Android Phone. I tested this app myself and it works perfectly. I would like to have a similar application written in C# running on a Desktop. I recently bought a BLE dongle (the cheapest option I found on Amazon) which I can pair successfully.
So far, I found solutions that involve using UWP, being one of those an example for exchanging data between a Windows Phone and a Heart Rate monitor, and very little documentation on how to accomplish that for Desktop applications here and here, that involve using System.Runtime.WindowsRuntime but no other information about how to connect to a device or listen to what is being broadcast.
Do any of you guys know if it is really possible to accomplish that? And if so, are you aware of a tutorial I could use to help me?
Thanks!
but no other information about how to connect to a device or listen to what is being broadcast
Here is an official and complete BLE client/server sample which you can use as a starting point
Look into the BTFramework library. We have worked with it for years. It took one afternoon to establish good communication with an ioT device this week. We are using C# NET, by the way. Their libraries have worked well on all platforms from the latest versions of Windows 10 all the way back to barely-functioning XP machines, skipping Vista of course.
As to the dongles you can buy... we support a commercial product using those dongles, and found their marketing claims don't always support their performance. Some work fine for a day, then fail, then work again. And one large batch from one vendor may work fine, but a batch purchased months later may have a high failure rate when you are pushing the envelope.
I'm currently working on getting a Leonardo device recognized and communicating with my app over a serial port in C# for the Windows 8 App Store. I'm using http://msdn.microsoft.com/en-us/library/windows/hardware/dn312121(v=vs.85).aspx#step2 as a guide, in conjunction with http://code.msdn.microsoft.com/windowsapps/USB-CDC-Control-sample-5ba19caa to guide me.
I'm having problems however in the sense that my Arduino device isn't showing up despite me entering my PID/VID and Class/Subclass/Protocol so I feel I'm missing some steps and was hoping someone that has experience with this could point me to a more specific/granular example.
My device is an Arduino Leonardo and I'm running windows 8.1 using Visual Studio 2013 Ultimate, code is in C#
Any help is appreciated!
Just general thoughts on regular windows applications (not aware of W8 AppStore):
Might help or might not, in the second case, sorry for wasting your time...
To get a "regular COM" device in Windows, without any additional drivers, you should make the device appear as USB Communication Device Class (aka CDC) - this is, among others, done via the appropriate class/subclass/protocol. The VID/PID don't care. This means the device should provide CDC/ACM USB descriptors to the enumerating USB host (windows) and implement the required endpoints and commands - supposedly there is already something existing for your board and you downloaded the firmware to it, right? You might want to try to connect such configured device to windows and after successful enumeration, new COM port should appear. If you program regular application, you just connect to such COM port via SerialPort class instance, no matter it is provided via USB subsystem... If this works, you should be able to start the AppStore part (where I have no clue how to help).
I'm just going to answer this as not currently possible. I ended up writing a desktop WPF application using metro UI/UX guidelines. Between that and ClickOnce deployment the store app feel is fairly well recreated, despite the store being ideal.
I sincerely hope that Microsoft decides to support this in the near future, the Metro SDK is really nice and I would love to eventually port it.
I've been given the task of building a Windows Mobile app for our company that quickly pairs a device by scanning it's bar code. I can discover the device, and talk to it, but I am stuck as far as pairing.
In C# / Windows Mobile 6, how do I pair a device? I don't really need to talk to the device within the app, I need to pair it so other applications can use it.
Is there an API I need to do this? I've seen things saying I need to register a pass key, etc? I can't seem to find any documentation on the actual pairing process, just connecting to it. (Just connecting to it, doesn't actually pair it.)
You can use my library 32feet.NET. Use method BluetoothSecurity.PairRequest See e.g. Bluetooth Security (That should work regardless of whether the device has Microsoft's own Bluetooth stack installed or the device has Widcomm/Broadcom or SSO Bluetopia).
The process of 'pairing' should also enable the services at the same time. If not we probably have other APIs for that too. Which services are used? SerialPort, others?
My company has an outsourcing partner that hosts data on a z series mainframe. Data is not in db2 but in some older structures. I guess vsam tables, if I haven't misunderstood those mainframe guys. We don't have ih-house knowledge of the mainframe technology. When we talk to partner's mainframe guys it sounds like they speak foreign language. We don't understand them, they don't understand us. PC world and mainframe world are quite different, yeah.
We access data through 3270 terminal emulator (IBM Persona Communications).
Teminal emulator does not connect directly to mainframe but rather to HIS 2000 Server (Microsoft Host Integration Server). HIS talks SNA to mainframe while clients talk tpc/ip to HIS server. We have an internaly developed helpdesk software (writen in c#) that monitors availability of other systems. Now we have request to extend the solution to monitor availability of the mainframe. The idea that we have is to start a 3270 session from our code. If connection suceeds system is available if not it's not available. We don't need to log in to mainframe and access any data there, just check if 3270 connection opens. I know this doesn't mean that actual data is available (sometimes data is locked by batch jobs and we can't access it even though system is up and running) but this approach is good enough for us. Could you point me to some documentation or existing projects? Can we use HIS or Personal Communications libraries. I haven't found any documentation on it.
Well, I finally got it.
I'm using Personal Communication api.
All functions exist in two dlls - pcsapi32.dll (pcsapi functions) and pcshll32.dll (ehllapi functions) that are part of Personal Communication installation.
Everything is well documented in IBM documentation that can be found on
http://publib.boulder.ibm.com/infocenter/pcomhelp/v5r9/index.jsp?topic=/com.ibm.pcomm.doc/books/html/emulator_programming07.htm
or downloaded as pdf.
I had to p/invoke native windows functions and had no problems with it. Tried to use host access code library automation objects but had some issues with it and gave up.
Found usable code example at codeproject site http://www.codeproject.com/KB/cs/all_ehllapi.aspx
I am not sure if the solution I have would work for you. I used IBM PC Communicator Emulator and connected it to MS Excel using the APIs available for it. You can have a look at the APIs coding documentation here - http://publib.boulder.ibm.com/infocenter/pcomhelp/v5r9/index.jsp?topic=/com.ibm.pcomm.doc/books/html/emulator_programming07.htm.
If you need sample code to connect to MF from Excel via 3270 Emulator please let me know, I can provide the same to you.
Regards,
Nitin
nsrivastava2 [at] gmail.com
Okay, so what I need to do is to write C# code, to integrate into an existing application.
I will (most likely) be using a Nokia 7230 mobile phone, and I'm willing to use the Nokia PC Connectivity SDK/API, or just AT commands over from C#, whatever works.
The catch here, though, is that I have absolutely no idea where to even start. I would be eternally grateful if someone could give me a step-by-step guide/tutorial on how to go about setting everything up. I've downloaded the newest versions of the PC Connectivity SDK, the PC Connectivity API, the PC Suite, and the Nokia Connectivity Framework.
If it's at all possible for me to test code with an emulator before actually purchasing a phone, that would be fantastic.
Thank you in advance for any help/advice.
GSMComm is a useful C# library for this, it comes with a bunch of samples/tools to mess around with as well.
I get the impression you going to buy a Nokia handset specifically to handle your SMS stuff? If so, you could just buy a GSM Modem (depending on your location) they are cheaper, don't include extraneous features and are not dependent on using manufacturer specific software.
What you are looking for is called an "SMS Gateway". Most of the articles on the internet discuss how to create one using Linux.
I did find this article though, which teaches you how to do it using C#: http://www.ozekisms.com/high-performance-sms-gateway/product-manual/index.php?owpn=315
It looks like you need the Nokia PC Connectivity API (note: Forum Nokia registration required for download):
Developers can use the Content Access API to build PC applications
that create, modify, and delete SMS and MMS messages. The API can be
used to send and receive SMS and MMS messages.