I haven't found any very good resources in my search for answers to this question. At present I am using a TI CC2540 HCI over COM Port. I would like to move away from this solution for cost reasons. Commercial bluetooth low energy USB dongles can be had for very cheap. Let's use a CSR8510-based device for example.
I would like to implement the host and application with the CSR8510 dongle acting as the 'controller'. It does not use a serial port for HCI transport. How can I send/receive commands from this controller? CSR Support is not interested in discussing this because my quantities are too low (~10k)
I would like to specify certain low level options such as connection parameters, scan modes (limited discovery, general, etc.) so I need a relatively high level of control over the 'controller' dongle. Writing a kernel mode driver is not a route I can take.
Example dongle
The linux kernel will handle a lot of stuff for you if you open up an HCI socket. You can also open up L2CAP sockets to make connections to devices. Unfortunately the documentation is lacking (I've actually never found any), but the source code is fairly readable. Take a look at the Bluez gatttool to see how they access bluetooth dongles via sockets.
Note: there's a nasty bug in kernels <= 3.4 where multiple L2CAP connections get mixed together when using an L2CAP socket.
Here's a previous answer I gave to another question with some sample code: bluez with simultaneous classic and low energy devices
Related
So I need to create a PC application, that can serially communicate via USB and Bluetooth to a hardware device.
EDIT: This device is being made by the company I work for and I will be working hand in hand with embedded programmer who will take care of software on the device. My only real concern is creating an interface on the PC and sending that information serially by either means to this device.
The vast majority of the application will stay the same including the serial data, the only difference being the type of communication.
I have a fair amount of experience in Java, some C/C++ and significantly more experience in Android.
I was thinking C# for the ease of GUI and it's .NET capabilities.
Any suggestions based on knowledge or experience would be appreciated.
Thanks
PS. Any information on how Bluetooth protocols vary between different PCs would also be very helpful
There are various suppliers of Bluetooth software for Windows: Microsoft, Broadcom/Widcomm, BlueSoleil, etc. They can each generally use any USB dongle.
Another good reason to go with .NET is that you can use my Bluetooth library which supports all of those stacks and more. :-) http://32feet.codeplex.com/
Connect with BluetoothClient etc. e.g. 32feet.NET docs -- General Bluetooth Data Connections
I've done exactly this with Serial over Bluetooth using an Arduino microcontroller. I used C# for interfacing with the micro, and XNA for displaying information (3D graphing).
Couldn't recommend it more as an approach, C# is really easy to use for serial.
Take a look at Visualising Serial Data: Arduino, I2C and XNA for detailed instructions.
Does anyone know a good library to allow us to programmatically monitor a parallel port (or LPT port) in windows. There are lots of good ones for Serial ports but I have had no luck yet for parallel ports. C# would be preferred but we're happy to do the Interop work if it's c / c++.
Thanks
You need a driver that gives access to the parallel port. The inpout32.dll solution is nearly universally used. It also lets you pinvoke helper routines to execute the INP and OUT cpu instructions. Everything you'd ever want to know about parallel ports, including coding samples for inpout32 is assembled at Jan Axelson's home page.
Are you looking for something like this? How to find available parallel ports and their I/O addresses using Delphi and WMI its in Delphi, but I think you can find WMI in C# too.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am looking for a book and or a code sample of how to do serial port redirection or port splitting. I write a lot of com port applications and want to write a monitor application that will allow me to watch the serial port between the application and the device.
So I want to be able to redirect the serial port to another port so I can monitor the data flowing between ports.
I understand in some cases this must be accomplished at the kernel level. (in USB cases)
I have written the monitor application using system.IO.Ports in C#. If I have to call a C++/C assembly that is fine.
Thanks
Joe
You might find that PortMon by Mark Russinovich is helpful in your work, although it isn't provided with source code. It will log all system calls related to a port, and has extensive filtering capabilities to keep that log to a manageable size.
Edit: PortMon works by injecting a kernel mode device driver into the system when it runs. That driver hooks the ports that it wants to monitor by inserting a filter driver into the stack. That filter driver reports all IRPs that pass through it to the application. This is not an easy beast to implement by any stretch, and it really can't be done in user mode.
The Windows DDK does have sample code for a port filter driver, but it is a lot of work to go from the sample to something useful.
A pure user mode solution that might work out is to use two additional serial ports to eavesdrop on the wire. A pair of USB to serial adapters and a bit of wiring will do what you need. Then it is only a "small matter of programming" to monitor and correlate the send and receive lines. A single chip solution could be based on the FT2232H device from FTDI, which has an available evaluation module. Add a couple of RS232 level translators and some D connectors and you've got a serial eavesdropper on USB that looks like two COM ports to Windows.
Another outside the box approach is that many logic analyzers and mixed signal oscilloscopes can do serial protocol decoding, often as an optional component. One source of inexpensive USB+software solutions is Saelig. I've bought chips and modules from them myself, but don't have any direct experience with any of the USB-based logic analyzers they sell despite thinking that I should have one in my bag along with the Netbook...
I wrote one, many years ago. The DDK (device driver kit) included sample source code for a filter driver for (i.e. immediately above) the parallel port driver: I adapted this sample to work with the serial port driver, and then added functionality such as monitoring and splitting.
This was serial ports, not USBs.
I also implemented another driver, which was a 'virtual' serial port, i.e. it implemented a serial port API but then redirected the data I/O elsewhere.
It was a lot of work (many months) to implement.
As always it depends on what you're going to do. If you need to mess around with how the lines between two serial devices are connected or need some 'good' timing informations, the best you can get is an external break-out box like Anthony already told.
If you just need some kind of monitoring you can go with PortMon or Serial Port Monitor.
Maybe you write two applications which are going to communicate over a serial connection. To get this done on a single PC without a local loopback cable you can try Com0Com.
Purchase a RS232 DB9 Serial Data Tap. This is a hardware device that is connected between the two serial ports and listens passively to the "chatter" between the devices. I used the following device for two-and-a-half years and it saved me significant amounts of troubleshooting time and effort. (I use to take it home every night to keep support technicians from "borrowing" it.) It is easy to make this device, but the following data tap is flexible.
"Tap in on a serial data stream and transparently monitor data activity. The output can be feed into a monitor printer or other device. Dipswitches allow programming to monitor the main transmit and receive lines, individually or together. No external power required, easy install, transparent connection Ideal RS232/Serial software development aid."
Alternatively, make or purchase a Serial Tap Monitor Cable. See the NST documentation for one possible configuration.
I strongly recommend you do not use a software solution because the monitoring software may be affected by physical situations.
We've got an application which needs to be able to use bluetooth for the following requirements:
Receive files from bluetooth devices (up to 2 devices at the same time)
Display all bluetooth devices in range
Send files to bluetooth devices
Scan for bluetooth devices and transfer files at the same time
We're running on Windows XP.
I've done some looking around and there seems to be 3 main stacks:
BlueSoleil
On the BlueSoleil website, in their SDK section, it seems to mention only 1 connection is supported, which is obviously no good.
Windows
Only seems to support 1 bluetooth dongle, which will probably mean we can't meet all our requirements.
Widcomm
Expensive and potentially overkill? More complex API? Thoughts?
In terms of SDK for C#, was looking at Franson Bluetools, anyone used this API?
Thanks
Firstly the disclaimer, I'm the maintainer of the 32feet.NET library. :-)
I've just checked, and on XP with the Microsoft stack (using one dongle) I can concurrently be receiving two OBEX PUTs and also discovering devices. That's using 32feet.NET's ObexListener class and the BluetoothClient.DiscoverDevices method. To send the OBEX PUTs one can use its ObexWebRequest class. To do multiple parallel connections with ObexListener I just had multiple threads calling its GetContext() method.
So that's maybe simpler than we thought...
I've also tested it with Andy Hume's OBEX Server using his Brecham.Obex library and the concurrent receive works fine there too. Its available from http://32feet.net/files/folders/objectexchange/entry6511.aspx.
On our Widcomm support. Hopefully it doesn't seem too "incomplete" on the client side... Inquiry (device discovery) and connections all work. The server-side still needs a little work however and there are some things the Widcomm API simply doesn't support eg. (programmatic authentication handling).
What was the issue with the samples? Compile-time or run-time? On MSFT stack or Widcomm? Follow-up at http://32feet.net/forums/37.aspx if you prefer.
Time to explain exactly what we ended up doing...
2 dongles why?
If a dongle is doing a scan the transfer rate is massively slowed down
A dongle can only support 7 concurrent transfers, if you are doing a scan, this drops to 6. If you want to send, receive and scan all at the same time, everything slows down, badly, and you are very limited in channels.
So, the idea is to run one dongle continuously scanning (so devices appear as quickly as possible) and the other dongle reserved for transfers, and since it's not scanning, transfers are nice and quick.
Library we used
After much testing and thought, we ended up opting for WirelessCommunicationLibrary from BT framework.
It supports Widcomm, Windows, BlueSoleil and the Toshiba stack. It supports all the server side stuff we need, is a well supported commercial product, which works perfectly without error.
Which stack?
Well, this is a complex one. NONE of the stacks support 2 dongles at the same time. So the only option is to run one dongle on one stack and the other dongle on another. This is where the WCL library comes in handy!
Microsoft - If an error occurs during a scan, it's common for the whole stack to crash out. This is not ideal! You have to close and restart radio device, it takes time and is fault prone. But... the Microsoft stack does handle file transfers very nicely.
Widcomm - Widcomm stack isn't great for file transfers. There is pesky little apps which install with Widcomm which keep trying to take control from your app. You can kill the bttray.exe, which helps, but you still get some strange behaviour from the stack during transfers. I'm sure this can be resolved, but since Windows is poor for scans, makes sense to use Widcomm for scans.
So... we've got one dongle set to Widcomm to scan over and over, and one dongle set to Microsoft set to handle only file transfers (in and out).
Getting 2 dongles to work
We went for using 2 of the same dongles, we can order them in bulk and stock them all the same reducing confusion. Each device shipped just needs 2 bluetooth dongles, simple.
The only problem is, these are widcomm dongles and we need one dongle on the Windows stack. Windows doesn't recognise these as Windows dongles, so won't register them for the Windows stack. So... the is a hack you can make to the bt.inf file to make it recognise the dongle for Windows. Then you need to switch the drivers for one of the dongles to run on the Windows drivers and you're all done.
Summary
So... we've got one dongle scanning all the time, one handling transfers, each on separate stacks and it all works nicely. This is the only way I have found to get 2 dongles working smoothly on Windows. If you've got a better suggestion, please post it!
Try this: 32feet.NET. Starting from version 2.4, they support Widcomm stack in addition to Windows stack.
BTW: Why you need to work with two dongles at the same time? Usually single dongle can handle up to 7 devices connected simultaneously.
Can any ony kindly explain that how we can take serial data as input from parallel port using c#.
Or the serial communication through parallel port.
I really wouldn't transmit your data this way as you are heading for a world of pain. Far better to use a serial to USB IC such as the excellent ones made by FTDI. In simple terms these take your TTL serial data send it via USB. Thanks to the FTDI drivers the data appears as a virtual serial port which your program can read from in the usual way.
Hope this helps.
Ian
It is not clear from your question if you are looking for a software or hardware solution. AN external serial to paralell converter (hardware) provides the simpliest solution.
If you are looking for a software only solution, you want to do "bit banging". Unfortunately this requires precise timing, something which may be extremely difficult in managed code. This sort of program is typically implimented in a lower level language such as assembler or C where one has direct access to the hardware. Here is another article specifically addressing the use of the paralell port for serial communications.
It sounds like you're doing something wrong. If you need serial input, why not use the serial port? I believe that the RS232 standard is widely supported. The parallel port is for parallel data transfers.