I need to write an application that can seat in the middle of a serial port communication between an application (3rd party, no source) running on my pc and a serial device connected to it (say on COM1).
The application normally communicates with the device as soon as you plug the cable. What I need to do is break this communication by "installing" my app in the middle so I can control what data goes through.
The only way I can think of solving this is creating a a pair of virtual serial ports (COM5<->COM6) using com0com. Then I would redirect the app to use COM5 instead of COM1 (I can set this in the app options) and then write a program that will copy every byte received in COM6 (sent by the application) into COM1 (sent to the device) and viceversa.
The problem is that I need to do this without introducing any delays into the communication, otherwise the application and the device will go out of sync.
I tried creating a C# console app to do this, but it seems to wait for a pause in the stream before raising the datareceived event, effectively introducing several ms of delay (speed is 9600).
What I would like to try now is to rewrite the program (maybe using the win32 api?) in such a way that it relays each rx byte as soon as it arrives, so the device would not notice any delay.
Can I do this using win32? Is there a simpler solution you can recommend?
Thanks
Maybe not much of a complete answer for your question but I think this might be worth a try.
Depending on your needs (you did not explain them) you can try to use Termite together with com0com. You can see a quick example here.
There is also an open source clone but I think the very feature you need (forwarding) was never implemented.
In any case, Termite allows scripting, so it is quite likely to be able to meet your needs.
Related
I have a BLE sensor that sends data at a frequency of 100Hz and I've developed an UWP application to receive this data. I'm having a weird issue where after a couple of seconds of everything working fine, I stop receiving notifications for new data.
Now, I say it's weird because this happens when I'm using the laptop's internal Bluetooth but not when using a Bluetooth dongle. When using the dongle it works fine and never stops. Both internal Bluetooth and dongle drivers are updated to the latest version Windows can find.
As soon as the notification stops the sensor disconnects.
The sensor is based on the Nordic nRF52832 SoC.
Now a bit of information about my code:
I have a Sensor.cs class in which I handle the connection and the streaming of the data.
I'm using BluetoothLEAdvertisementWatcher in order to find the sensor.
The GattCharacteristic's are private members of the Sensor class.
I subscribe to notifications by calling:
await _gattDataSensorsCharacteristic.WriteClientCharacteristicConfigurationDescriptorAsync(
GattClientCharacteristicConfigurationDescriptorValue.Notify);
The application doesn't do anything fancy. Just connects to the sensor, starts the streaming and prints the data.
I've done quite a research and couldn't find anything similar. I've found posts about notifications stopping because the object was taken away by the GC, the characteristics were local variables instead of class members or calls weren't awaited.
Why does this happen?
1st edit
#Emil I'm sorry, my fault for not mentioning that as soon as the notifications stop, the sensor disconnects. I'm editing the question to mention that as well as it's something relevant. Anyway I'm trying what you mention asap.
#GrooverFromHolland That option was checked. I've tried unchecking that option on a couple of computers but sadly, unchecking it only makes the code last a few seconds longer.
#Nico Zhu - MSFT I've followed the link you posted and read the doc also went to my sensor's manual to double check if the characteristic allows Notify and it does, it does allow Read and Notify. I also do the same thing characteristic.ValueChanged += Characteristic_ValueChanged; as it's mentioned in the doc.
About the sensor disconnecting when the notifications stop/the valuechanged stops firing. I have to add that on my MainWindow, the sensor object is a member class and it isn't disposed at any moment. So it doesn't make sense that the GC takes the object away, right?
2nd edit
I've tried the code I'm using with both the laptop plugged and unplugged to a power source and it's always set to max performance. The code I'm using can be found here: link
3rd edit
Following #Emil 's recommendations I was finally able to scan the traffic. Tried to understand what the pcap file generated by USBPcap, but I simply don't understand. I've tried the issue with 2 sensors and the disconnect/notification stop pattern looks different for each sensor.
I've made a Dropbox folder containing the two pcap files: link
From what I understood, in the file "ble-FE592382586F.pcap" the interesting line No are: 12647 and 12681. It says the source is the controller and the destination is host. Is the controller the laptop's bluetooth driver?
Controller means the bluetooth chip (inside or outside the computer) and host is the main cpu. They talk with each other over usb. At packet 12681 in the first file, the disconnect reason is Connection Timeout (0x08). This means the connection was dropped unexpectedly (radio interference/bad signal?). At packet 613 in the other file, we have the same situation. A difference is that in only in the second file, there was a new attempt to reconnect the device.
Since you do not use bonding, you must make sure to re-write the client characteristic configuration descriptor upon every new connection. It doesn't seem like you do this.
I ran into similar - what I discovered was that the GattCharacteristic (the object you call WriteClientCharacteristicConfigurationDescriptorAsync on) was getting GCed - as soon as I added that to a class-wide variable (I made a Dictionary of all the characteristics I was tracking), my notifications kept coming
We should monitor and log ~1000 devices (1..4 sensor per device). SMS and email alert and the common functions are required if anything going wrong.
I think we instead of developing the whole ecosystem in .NET/C# it would be nice to use an existing one - for example Zabbix. But is it possible without any bigger hack?
I think that the main problem is that the devices are old-school and using RS232 for communication.
Any idea or any other flexible monitoring software?
Zabbix is a good monitoring tool, and it's easy to configure sms and email alerts. You'll need to script the serial port check, as there is no built in support for that. This may help: http://ramblings.narrabilis.com/node/310
I was wondering if anyone knows how (or even if it is possible) to monitor and trigger an action when a computer running windows (7-8) starts reciving a file transfer from over the network onto one of its drives.
Bonus points if I can find out how big the file is that the other guy is placing on my machine and how much is done etc...
I want to know if there is any API in windows, or snippit of code, or some other API that provides any of this functionality.
I still want to be able to recive files, I just want to manage them better. I am on a network with over 90 computers and this software that I wish to write would be running on most of them.
Of course you can (after all it's what an Antivirus program does) but it's NOT easy and probably you'll see it's more comfortable to do in C than in C#. I'm sure there's a .NET porting of WinPCap anyway you can always P/Invoke.
Start reading about Network Monitor SDK on MSDN. It's not an easy task, you have to capture a specific set of frames, you may use a Network Packet Monitor to inspect the content and the type of the packets you have to capture and parse.
I'm not sure but you may take a look to QoS API (start reading this article), it should provide something you can use.
I have an Arduino mega communicating over Bluetooth (bluesmirf gold device) to a C# application that I wrote. The Arduino is constantly sending a serial signal of 32 characters, the first always being an "S" and the last an "E". Using putty I can confirm that this signal is being sent correctly 99% of the time.
Now I want to read this signal with my C# application, which I am doing with the following code:
public string receiveCommandHC()
{
string messageHC = "";
if (serialHC.IsOpen)
{
while (serialHC.ReadChar() != 'S')
{
}
messageHC = serialHC.ReadTo("E");
serialHC.DiscardInBuffer();
}
return messageHC;
}
serialHC is of the serial class.
Sometimes this works perfectly but other times I'm having problems, I cannot find out why it works sometimes but others not.
The problem that I seem to be having is that sometimes I get a rather large Lag in the data that I am reading from the arduino. I notice this because I am sending button states and they only change a few seconds after I actually press or release the button on the Arduino. I used the standard baud rate of the Bluetooth device, which is 115200, and was wondering if changing that to a much lower rate could yield better results? What if any advantage would that have? I do not need hight communication rates, even updating the state 4-5 times a second would be acceptable for my application.
Is it possible the lag is coming from my code? I think it may be from the while loop that is waiting for the incoming "S" but then I don't see why it should hang there since there are new signals always coming in at a high rate.
I'm using the DiscardInBuffer() because I do not care about outdated data and just want to skip over that. It is much more important that I am reading current up to date data and acting on that fresh data.
Thank you for your help!
Best regards,
Bender
Update:
Just found out a bit more information while debugging. The problem only seems to appear:
When connected over Bluetooth (over USB cable there is absolutely NO Lag)
When a second Bluetooth connection is established from the PC to another device (different COM port and different baud rate)
Does anybody have any experience running two different devices off the same Bluetooth dongle on the PC? I can manage to connect to both no problem but still having the lag issue mentioned before.
Thanks for any help
You are not really using a physical serial port here. The BlueTooth driver merely emulates one. This is common, the Windows API has a well defined set of api functions to talk to a serial port. Emulating one makes the interface to the driver simple, the vendor doesn't have to supply an interface DLL or document a complicated DeviceIoControl() protocol.
Which means for one thing that the actual communication settings don't matter. Baudrate is meaningless in this scenario, it is the BlueTooth radio signaling that sets the transfer rate. The driver will accept whatever you select but will otherwise ignore it. Handshake signals might be interpreted, it's up to the driver to implement them. Communication error reporting is very rarely implemented, BlueTooth has an error correcting protocol, unlike a real serial port.
No, the loss of data here is entirely self induced. Clearly the driver does implement DiscardInBuffer(). Which accomplishes nothing but throw away any data that the driver received. This goes wrong if your code runs a bit late or gets interrupted by a thread context switch.
Delete the DiscardInBuffer() call.
I have a Program that uses serial port communication to talk to some hardware. No problem.
Then I added two GSM Modens to the picture. In VB I opened the COM port to the modem with one protocol (8 data, none, 1) and when the communication between modems was open and running I closed the port and reopened it with a new protocol (7 data, even parity, 2 stop) to my hardware. The hardware is standardized to this speed several years ago so I can not change this and most modems do not support 7, e , 2 protocol.
I want to expand the support of modems and many of them break contact when the port is closed. I'm not using hardware handshaking.
So here is my question.
How can I best change between protocols with out closing the serial port?
Does anybody have another idea how this can be done without changing any hardware settings?
Make a virtual serial port? (how?)
Ideas?
To truly set all options of your serial connection you should use the Win32 API communication functions. As far as i know you don't need to close and re-open a port to get these settings active. The will work right after setting them (like in this example).
You just have to take care, if you want to change just one or two settings, that you have to prefill you structure with the corresponding GetX function, make your changes and call the SetX function.
Maybe in contrast to the sentence before, but don't rely on default settings on your first SetX call. I've seen a lot of programs just altering the popular settings (e.g baudrate, stopp bits, etc.) but not the rare ones (like XoffChar, etc). If you just do that and another program will change these settings you start wondering why your program is suddenly not able to communicate anymore with your serial device, because you use the settings which another program set to the serial port.
And before i forget, if you like to use Win32 API functions in C# take a look at PInvoke.net