I am trying to read BLE telegrams sent to a usb plugged reciever to my PC.
I am using a serial port reader ( used putty at first then tryed some other software from the net). However, I get nothing, not data at all sent; not from my sender not even any telegram from may be other unknowm devices that may be there advertising.
I have run mode on command line to give me information and it shows that my com port has a baudrate of 1200.
I must say this value was not fix it goes from 1200 to 57600.
I know that my data is sent at a baudrate of 57600: so I'm thinking may be the problem is that the baudrates being different it can't get the data but then it should come to a time where I can see at least some insignificant data of incomplete telegram. I have also tried to change the baudrate on the serial com port reader but same result nothing at all.
My question is what might be the problem and how can I fix it ? in other words having a BLE reciever and tranciever how can I read the telegrams on COM ports
Related
Currently I have a server, that communicates with a projector through a RS232. The server opens a com port when the projector is connected. The same happens to any PC when a certain type of device is connected through the USB (lets say an Arduino for example). What I want to do it basically replace the projector with a PC/Arduino/Raspberry without the server noticing anything. That would mean the server will recognise the connected PC and open a COM port for it. What do I need to do on the PC so that it automatically opens a com port on the server? I guess there is something very basic that any printer, Arduino, projector etc does, that computers recognise it as a "com port device".
P.S. Doesn't matter the OS on the PC, I just need to make it work and then implement w/e I need to do with the established communication over the port.
P.S.2 I've searched a lot about it, but probabl I am doing it wrong, because I didn't find my type of question anywhere.
COM ports are basically hardware that is detected by the system. Let's say, if an Arduino is connected to a PC, it has its onboard USB to TTL converter which can be found in the device manager(if using windows). Similar USB to TTL converters are there in the market like CP2102, PL2303 which acts like a COM port even if no device is connected further to it. it may be possible that the program you are using(as you referred server) may be sending some data over the serial port and verifying the hardware.
What you need to do to replace it is, first of all, find the baud rate at which the communication is going on, then, listen over the serial lines which machine is sending which message in the sequence(there must be a handshake as I mentioned earlier), if a complicated algorithm is not used by the device, you can simply mimic the device by sending same messages over serial.
So has anyone done this?
I'd like to store a hex file on an SD card and just blast it to any boards I have with the catarina bootloader on them when I connect to my uploader device.
This seems to be the correct protocol to talk to the catarina bootloader (the command definitions are at the end.) http://www.atmel.com/images/doc1644.pdf
If I manually force it into programming mode from COM4 by setting it to 1200 baud and closing the port, then opening COM5 and sending it one of the commands I do get a response as I would expect but even if I put it in programming mode by sending "P" it dropps back out after a second or two and doesn't stay in programming mode as I would expect.
It seems that the timeout gets reset/extended if certain commands are sent so I guess that makes sense.
Please feel free to slap me and send a link if this question has already been answered; I just couldn't find it. I did search though.
I've been trouble-shooting communication with a serial device. In looking over lots of documentation, I now understand what the settings for "baud rate," "data bits," "stop bit," and "parity" mean. But what I can't seem to understand is who (sender or receiver) determines these settings.
Say I have a serial device plugged into my computer. In my code, I open a connection to the serial port and specify something like 9600,8,E,1. When I specify these settings, do these get sent to the sending itself, so that it knows how to send the data to my receiver? Or is it more common for a sender to expect a receiver to comply with strict settings?
The issue I'm having is that I attempted to use "Even" parity, and that resulted in tons of irregular transfer errors. When I use "Odd" parity, however, those errors go away. There is also a USB to Serial adapter involved in my set up. There aren't any transfer errors with Even or Odd parity without the adapter in the middle. So I'm just having a hard time understanding whether the device itself doesn't support sending with Even parity, or whether the adapter is the thing causing trouble, etc.
Thanks.
When I specify these settings, do these get sent to the sending itself, so that it knows how to send the data to my receiver?
No.
To expand on the comment by Hans Passant, both sides of the serial port have to agree on the settings, otherwise they won't talk to each other. If they don't agree, you will get gibberish data on either side as the hardware will read the data at an incorrect time. The settings are normally documented in the manual for the device that you are attempting to communicate with. For example, to communicate with a Cisco router, you will generally use the following settings:
Bits per sec : 9600
Data bits : 8
Parity : none
Stop bits : 1
Flow control : none
When you setup the serial port on your side, you must use these same settings, there is no hardware-level handshake between the two devices that determines the speed that they will communicate at.
Sometimes, the format for the serial port settings may be given in a format like the following:
9600,8,N,1
Which is just shorthand for the above quote(9600 baud, 8 data bits, no parity, 1 stop bit)
In my experience, most devices default to 9600,8,N,1, the next common serial setting is 115200,8,N,1
I am trying to connect a joystick to my pc. The device has a serial cable which is supposed to be inserted into another device (a steering wheel), but instead I want to use it directly. Eventually I plan to connect it to a program that am currently writing.
How can I communicate with this device? I know how to communicate to a serial device, I just don't understand what I should send and expect to receive.
Debugging attempts:
If I connect it directly to my PC's serial device and using a program such as moserial I can sort of communicate with it, if I pound on the keyboard it returns (usually) one byte and "=\n" per byte sent. The return codes do not seem to always correspond to the state of the joysitck. It seems to be returning the same value for the same value. Once or twice I noticed that if I send a large amount of random data I can get it to hang until I switch the position of the joystick. But for the most part there seems to be nonsensical responses (same input per output regardless of state). I also tried a serial-to-usb converter which had a different result. Under USB the device does pretty much nothing regardless of the baud rate. I have noticed that if I send an incredible amount of random kepresses I occasionally get a single unprintable character in response.
I was expecting to get a continuous stream of numbers corresponding to the state of the joystick.
Summary:
I don't know if my direct serial connection is just showing noise, I did try a second serial to USB converter which had the same results. Any ideas or suggesting in determining how to communicate with this device?
I currently have an embedded device connected to a PC through a serial port. I am having trouble with receiving data on the PC. When I use my PCI serial port card I am able to receive data right away (no delays). When I use my USB-To-Serial plug or the motherboards built in serial port I have to delay reading data (40ms for 32byte packets).
The only difference I can find between the hardware is the UART. The PCI card uses a 16650 and the plug/motherboard uses a standard 16550A. The PCI card is set to interrupt at 28 bytes and the plug is set to interrupt at 14 bytes.
I am connected at 56700 Baud (if this helps).
The delay becomes the majority of the duty cycle and really increases transfer time. (10min transfer vs 1 hour transfer).
Does anyone have an explanation for why I have to use a delay with the plug/motherboard? Can anyone suggest a possible solution to minimizing or removing this delay?
Linux has an ASYNC_LOW_LATENCY flag for the serial driver that may help. Whatever driver you're using may have something similar.
However, latency shouldn't make a difference on a bulk transfer. It should add 40 ms at the very start of the transfer and that's it, which is why drivers don't worry about it in the first place. I would recommend refactoring your transfer protocol to use a sliding window protocol, with a window size of around 100 packets, if you are doing 32-byte packets at that baud rate and latency. In other words, you only want to stop transmitting if you haven't received an ACK for the packet you sent 100 packets ago.
You'll probably find that different USB-Serial converters produce different results. We've found that the FTDI ones work well for talking with embedded devices. Some converters seem to buffer the data for a long time and/or fragment it.
I've never seen a problem with a motherboard connection - not sure what is going on there! Can you change the interrupt point for the motherboard serial port?
I have a serial to usb converter. When I hook it up to my breakout box and create a loopback I am able to send / receive at close to 1Mbps without problems. The serial port sends binary data that may be translated into ascii data.
Using .Net I set my software to fire an event on every byte (ReceivedBytesThreshold=1), though that doesn't mean it will.