I have a c#/unity application which utilizes serial port to establish bluetooth connection with one device which then sends some data in real time back to the application.
The problem is, that sometimes, it seems like totaly random, but at least once a minute, serial port connection/data transfer speed drops dramatically, device buffer is filled an thus data is lost. Turning wifi on makes matters even worse but predictable. When I tur on wifi data transfer speed dropps emidiately but in cca 3 seconds grows back to normal.
Tryed the same aplication on another similar computer and it is a bit better - speed dropps less often, and also ona a android device where it dropps even more often, but picks up the slack almost right away.
Are there any serial port settings or Sistem settings that should I take into account. Is there a way to solve this problem in code.
thx
Without code samples in your questions it is hard to give a good answer.
But from the sounds of it you are probably getting interference on the 2.4GHz radio frequence that your bluetooth device is on.
Wi-Fi is perhaps the biggest and most problematic one, as are other Bluetooth receivers and devices, which can interfere with one another.
Microwaves , Direct Satellite Service, 2.4GHz and 5GHz phones, wireless speakers, external monitors, baby monitors, and any wireless device that talks over a 2.4GHz radio frequency can interfere with your signal.
Things you can do.
1) work in a quite RF environment. one with out a lot of other devices communicating
2) physical materials can cause all sort of RF issues. Reflections / Collisions. Try to remove any physical barriers that you are communicating though. Stay away from Fluorescent Lighting and Microwaves ( both emit 2.4 GHz )
3) move your devices closer together
Because this is run as a virtual com port there are no Serial Port or System settings that can positively affect this. Might have more luck implementing your own bluetooth device driver.
Related
I want to make a Desktop application with WPF(.net 5). In this application, I want to connect various hardware devices(sometimes simultaneously) via a USB port, Serial ports/Com port (e.g. RS232), etc.
I want the application to talk both ways. Receiving data from hardware devices with a range of configurations(i.e. baud rate, frequency, data string), and Sending data to display, modify settings of the device.
I don't have any idea about where to start in WPF | .NET | C#. Are there any inbuilt classes, APIs to achieve this?
Devices I want to connect are;
Serial port: Weight Scales, 7 Segment Displays, Liquid Analyzers
USB port: USB sticks containing text, JSON files; If one of the above serial port devices has a USB variant then those are too.
There is the Serial port class in .Net, but you might want to read some criticism about the class before using it. There are also libraries available to communicate over USB.
But these are fairly low level protocols that does not know what kind of device is on the other end. So your UI would therefore also need to low level, i.e. send/receive raw data. And this would mostly be useful for expert users using very specialized devices. While you could probably make the part that sends and receive data share an interface for both USB and Serial, connection and setup would probably need to be handled differently, since these are handled differently for serial and USB.
If you want a easier to use UI you would need to know more about what kind of device it it. There is a number of standardized USB device classes that specify what kind of device it is, and there are often high level APIs to interface with these devices. But that would require coding a module for each individual device class.
So I would recommend to start with figuring out what you really want to do? Connect to a IO board with some general purpose IO pins? Connect to some specialized device like a PanTilt unit? Read data from a webcam? Read some data from some kind of sensor, do some processing and control some kind of output device?
I wonder if its possible to check if a WOL-request has been
received during the computer is already turned on. (pInvoke, c#?)
If the computer receives a magic paket and boots, Windows writes an corresponding event-log entry to the System-Log.
The way i'm looking for is not to listen to my UDP-Traffic by my own - if its possible i want to know how to receive a kind of system event (IRQ?) or something.. And thats all when receiving PC is already turned on.
I agree with Duston that WOL is a Layer 2 combined with hardware thing. On a normal working PC, there is little chance that the NIC hardware will pass this on to the drivers, as it is exactly the task of this hardware to only disturb your CPU if really needed.
You best chance to see a magic packet on a working PC would be : install and run sniffer (packet analyzer) software. That will force a supportive NIC into a special mode that transfers every packet to the CPU. If you can now see the magic packet in the output, next step would be to configure the sniffer to alert you in case it sees a magic packet. Done. All this will be quite CPU-intensive.
You could write software that performs all this, but that would essentially be rewriting the complete sniffer with fixed query instead of a configurable one.
I have been reading up on the web and cannot find any information on working with a RS485 MultiDrop connection in c#
To give a bit of insight. I have written an application to communicate with a Serial device using the MODBUS RTU protocol. Now the client has informed me there devices may be hooked up using multidrop communications links. Being a novice when it comes to working with serial devices I am a bit lost here.
My question is simply: Where do I start? a Google search has thus far only produced hardware converters and wikipedia entries for different Serial Communication standards.
Thanks!
RS485 is a standard that defines the electrical characteristics of a particular multi-drop networking arrangement. I once used it as the internal bus for an instrument - the main control board drove various pumps which were arranged on an RS485 network.
You can get half-duplex and full duplex arrangements (half means that one device can talk at a time - full means send and receive can happen at the same time).
Really using it is not a whole lot different from using an RS232 or serial port, and as you've seen you can get serial to RS485 converters. You can use the serial port drivers in C# to use it.
SerialPort Class
Your main problem is that RS485 doesn't really address how it should be used - its a fairly low level electrical spec, it doesn't define how you should use it to make communication happen.
The main issue you need to consider is how you're going to coordinate all this. With RS232 - there are two things connected, which makes it easy - usually a computer and some device. With RS485, there are many things connected. So you need some way of addressing each device. You don't give any details about the 'device' referred to here - but if they are intended to be connected on RS485 - then there will be a way of addressing them. There are however several ways this could work - so I can't help you on specifics without more detail. With the system I developed, all communication was initiated by the 'master' device (i.e. my control board - or your c# application for example) and each message sent had the receiver's address on it - so the right pump knew that the instruction was intended for it.
I hope this is of some help. Really its not that complicated, but you need to think about what these devices do, how they are addressed, and think about the messages that you need to send back and forth. You can use the C# SerialPort classes to actually do the work.
The book referred to in the other answer looks great by the way. I really would consider buying it if this is all new to you. It covers serial port communications, and has a chapter on RS485.
I have not worked with RS485 but this book can be a help in understanding Serial port and USBs.
here is another link which discuss specs and here is another. I dont think they will be readily implemented in C# but could be.
I am working on an application that needs to control another device.
This control should be using Wi-Fi.
How can this be done in C#?
Important to know that the other device I want to make it.
I can afford the part of making and design but how to make it connect to PC using Wi-Fi?
I don't know about it.
I just need a key to start searching or some thing similar.
Connecting over Wi-Fi could be as easy as opening a socket on the server, and another on the client, and start streaming data. Of course this if both devices are compatible and has Wi-Fi receivers. Just think of them as two computers connected with a wire, or without a wire they will just behave the same.
The connection protocol will care about doing the magic of converting what you write on the socket, into RF signals received from the other device and converted back to bytes.
But if you are building your own antenna/receiver/protocol ... then things will be much more complicated.
If you have to ask then you're probably going to want a single board computer. Popular choices are:
gumstix
Zii EGG
nwg100 by Atmel
(XBee) --not too sure about these, I haven't used.
You can install a network stack and everything on them.
I've written some C# code that checks whether a device is present on any SerialPort by issuing a command on the port and listening for a reply. When I just set the port speed, open the port, get the serial stream and start processing, it works 100% of the time. However, some of our devices work at different speeds and I am trying to probe for a device at various speeds to autonegotiate a connection as well as detect device presence.
When I do all this in a single thread there are no problems. However, 3s timeout at ten speeds is 30s per serial port, and there may be several. Hence the desire to probe all ports concurrently.
Sometimes this works. Sometimes Vista bluescreens. When I use threads to probe all the ports simultaneously it nearly always bluescreens. When I force everything to run in one thread it never happens.
A USB-serial Prolific PL-2303 adaptor is in use with x64 drivers.
#Vinko - thanks for the tip on reading minidumps.
As near as I can tell, the crux of the problem is that by starting a new asynchronous I/O operation from a different thread it is possible to give a whole new meaning to overlapped I/O, inducing a race condition inside the driver. Since the driver executes in kernel mode, BLAM!
Epilogue
Except for kicking off, don't use BeginXxx outside of the callback handler and don't call BeginXxx until you've called EndXxx, because you'll induce a race condition in driver code that runs in kernel mode.
Postscript
I have found that this also applies to socket streams.
Having written Windows drivers for one of these sort of device once, my advice would be not to waste your time with WinDbg trying to prove what you already know - i.e. that the driver you're using is buggy.
If you can find a more up-to-date driver from the PL2302, then try that, but my recommendation is that if you have to use USB->Serial adaptors, the FTDI-based ones are the best. (They're not the one I wrote the drivers for, either...)
You can also disable "Automatic Restart" under System Properties\Advanced\Start and Recovery\Settings. Once you disable that, you can see the BSOD and look for the error message, e.g. IRQL_LESS_OR_EQUAL, by searching for that error name, you can usually narrow down to the source of the problem.
Btw, not many notebook comes with serial ports nowadays, so you must be using USB-Serial converter? If that's the case, the driver might have been an issue to start with, since most manufacturer wrote the serial port driver as virtual driver.
BSOD usually means buggy drivers.
What kind of HW ports do you use? I've had BSODs with SiLabs CP21xx USB to Serial converters drivers.
There are FTDI drivers that are stable under x64 vista and win7. I second the person who said to use FTDI chipsets only.
Most of the cheap serial to usb dongles at the shops near me (Toronto, Canada) seem to be FTDI chips. It's never on the box, so I buy one, and if it's good, I go buy a box full of them.
W