I'm reading some frames from the infotainment system, and I get multiple frames that forms a "package" (let's call it that) which forms a text. Each frame sent by the radio unit is received by a display module that sends back a confirmation frame (like a acknowledgement) with the same data, except for the last frame of the package sent by the radio, on which the confirmation frame is different from the rest with one bit. Tested for a long time on multiple messages.
Now, in order to remove the display, I need to know how long (how many frames) the package is, to use it in my application, but without that different acknowledgement frame sent by the display module, I am unable to continue my project.
My question is, how does the display module knows how many frames does it need to receive? Is it possible to be in one of the bits on the first frame received (I've tried checking, but none of the bits have a pattern related to the package's number of frames length)? Is it something else? I know about the acknowledgement bit on the frame, but that is just for checking if any device received that frame (there are about 6 modules on that CAN network, so that's why I believe the display sends confirmation frames).
I am a begginer in CAN, so any useful information is welcomed.
So it seems this kind of package, which consist of more than 7 bytes of data, uses the ISO 15765-2 protocol, that specify in the second byte of the first frame how many bytes do the package contains.
Related
I am transmitting and receiving data using aux cable and GNU RADIO between two laptops.
I have implemented DQPSK using PSK mod block.
The problem is that while receiving I have to provide a delay, some integer value e.g 0,1,2 etc.
It is different every time.
Is there a way to dynamically check for the right delay value or any other workaround to this situation?
I have written 'start.' at the start of data being transmitted and 'end.' at the end.
I have to give a demo for this project and I dont want to manually change the delay at runtime.
I cannot find the .cc file of file sink in GNU RADIO, I can change the C++ code according my requirement but there is no such file.
Below is the screenshot of the grc file on the receive side.
Any help will be appreciated.
Since there's no way for the receiver to know when the transmitter started transmitting, it decodes stuff before there's actually anything to decode.
In essence, you need some kind of preamble or so to tell your receiver when to start – side effect of having something like that would be that you could correct some things (the two sound cards don't share the same oscillator, which leads to a symbol rate offset, and a center frequency offset).
You basically added that framing - your start. and end. strings.
I cannot find the .cc file of file sink in GNU RADIO, I can change the C++ code according my requirement but there is no such file.
It's in gr-blocks/lib; however, you shouldn't modify the file sink. Really,
I'd recommend you take the time to go through the guided tutorials, use gr_modtool to generate a general block which has a state machine that looks for the bits of your start string and drops everything before and including those, and then passes everything till it sees the stop string. That all can be done with a single state machine, and a bit of python or C++ code.
We have a group of users who need to see the payloads of packets in wireshark captures. I'm looking for a way to remind them users that the data contained within may not represent the exact frames on the wire (because the capture will have been pre-processed by the time they get it to remove, e.g. security-sensitive IP addresses). A hook in the capture file that triggered a popup with a short message would be perfect. Is there anyway to do this, short of wrapping Wireshark with another binary (which would be trivially bypass-able anyway)?
I've searched in the wireshark lists but come up empty.
The only thing you could do would be to have the pre-processing program write out the file in pcapng format and add a comment to the initial Section Header Block giving that warning. That won't produce a popup - but, then, not all the capture file reading programs in the Wireshark suite are GUI programs that could produce a popup.
I am using the following few lines of code to write and read from an external Modem/Router (aka device) via IP.
TCPClient.IOHandler.Write(MsgStr);
TCPClient.IOHandler.InputBuffer.Clear;
TCPClient.IOHandler.ReadBytes(Buffer, 10, True);
MsgStr is a string type which contains the text that I am sending to my device.
Buffer is declared as TIdBytes.
I can confirm that IOHandler.InputBufferIsEmpty returns True immediately prior to calling ReadBytes.
I'm expecting the first 10 bytes received to be very specific hence from my point of view I am only interested in the first 10 bytes received after I've sent my string.
The trouble I am having is, when talking to certain devices, the first byte returned the first time I've sent a string after establishing a connection puts a rogue (random) byte in my Buffer output. The subsequent bytes following are correct.
eg 10 bytes I'm expecting might be: #6A1EF1090#3 but what I get is .#6A1EF1090. in this example I have a full stop where there shouldn't be one.
If I try to send again, it works fine. (ie the 2nd Write sent after a connection has been established). What's weird (to me) is using a Socket Sniffer doesn't show the random byte being returned. If I create my own "server" to receive the response and send something back it works fine 100% of the time. Other software - ie, not my software - communicates fine with the device (but of course I have no idea how they're parsing the data).
Is there anything that I'm doing incorrectly above that would cause this - bearing in mind it only occurs the first time I'm using Write after establishing a connection?
Thanks
EDIT
I'm using Delphi 7 and Indy 10.5.8
UPDATE
Ok. After much testing and looking, I am no closer to finding this solution. I am getting two main scenarios. 1 - First byte missing and 2 - "introduced" byte at the start of received packet. Using TIdLogEvent and TIdLogDebug both either show the missing byte or the initial introduced byte as appropriate. So my ReadBytes statement above is showing consistently what Indy believes is there (in my opinion).
Also, to test it further, I downloaded and installed ICS components. Unfortunately (or fortunately depending on how you look at it) this didn't show the same issues as Indy. This didn't show the first byte missing nor did it show an introduced byte at the beginning. However, I have only done superficial testing, but Indy produces the behaviour "pretty much straight away" whereas ICS hasn't produced it at all yet.
If anyone is interested I can supply a small demo app illustrating the issue and IP I connect to - it's a public IP so anyone can access it. Otherwise for now, I'll just have to work around it. I'm reluctant to switch to ICS as ICS may work fine in this instance and given the use of this socket stuff is pretty much the whole crux of the program, it would be nasty to have to entirely replace Indy with ICS.
The last parameter (True)
TCPClient.IOHandler.ReadBytes(Buffer, 10, True);
causes the read to append instead of replace the buffer content.
This requires that size and content of the buffer are set up correctly first.
If the parameter is False, the buffer content will be replaced for the given number of bytes.
ReadBytes() does not inject rogue bytes into the buffer, so there are only two possibilities I can think of right now given the limited information you have provided:
The device really is sending an extra byte upon initial connection, like mj2008 suggested. If a packet sniffer is not detecting it, try attaching one of Indy's own TIdLog... components to your TIdTCPClient, such as TIdLogFile or TIdLogEvent, to verify what TIdTCPClient is actually receiving from the socket.
you have another thread reading from the same connection at the same time, corrupting the InputBuffer. Even a call to TIdTCPClient.Connected() will perform a read. Don't perform reads in multiple threads at the same time, if you are using the threads.
I'm working on an embedded home surveillance system. I want to interface a couple of serial-enabled JPEG capture cameras, maybe a couple of door sensors, etc. Problem is, I can't for the life of me figure out how to interface a camera to a microcontroller. Stills, streaming video, it doesn't matter - I can't find any how-to documentation on this.
I understand serial communications, and most of the camera documentation I've found out there describes the protocol necessary to instruct the camera to send the datastream down to the uC for capture. What they don't show is what you're supposed to do with the data once you get it.
Here's an example.
They show a great little video, and the datasheet describes which bytes must be sent to the camera to retrieve the image. What I need is an example or tutorial of some sort that will explain what to do with the stream of bytes that make up the image itself. How do I arrange those bytes into an image and save it as a file?
I've looked all over the place for a tutorial of some sort, but have come up dry. I'm not sure which processor I'll use for this project just yet, but this question isn't really processor-dependent. All I need is the algorithm, maybe a peek at a library, if one exists. I'll take that process and adapt it to my hardware, I just can't seem to find a place to get started.
Have any of you done this?
I think the details are pretty clear in page 10 inside this document:
http://www.4dsystems.com.au/downloads/micro-CAM/Docs/uCAM-DS-rev4.pdf
First, one package is between 64 to 512 bytes - flexibly defined by the programmer. Image size is the actual JPEG image itself....nothing more or less....just pure JPEG image. So the equation to calculate the number of package based on image_size / package_size is given in page 10.
Next, is that (package_size - 6) is to be consistently used everywhere, because 6 bytes are used up for non-data purpose, so (package_size - 6) will be just the data - but u have to reassemble it yourself.
To assemble the data from the package, u have to strip the 4 byte header + 2 byte trailer and concatenate all these from all the package sequentially one after another.
Other facts:
a. "Set Package Size" command must be sent from host to CAM - before "SNAPSHOT" command, which capture the image from the camera into the CAM memory buffer.
b. Next is to send "SNAPSHOT" command to capture the image into memory buffer.
c. Last is to send "GET PICTURE" command (only one time, but data will come back multiple times - see diagram in page 15) to extract out all the images....and it will come back in the form of "package" as we have defined the size earlier in "set package size". Since u have calculate the formula u will know when to stop asking for the next package. And there is a verification byte - u have to used that to make sure data is correct.
I have not used this camera but looks like it works exactly the same is a camera (C328) I have used. Send an image resolution/colour command. When you want get an image send an image capture command. The camera responds by sending a binary file over the serial link.
When I was writing a simple server for a simple client <> server multiplayer game, I thought of the following text-based protocol using a translation library. Basically, each command had a certain meaning, eg:
1 = character starts turning right
2 = character starts turning left
3 = character stops turning
4 = character starts moving forward
5 = character stops moving
6 = character teleports to x, y
So, the client would simply broadcast the following to inform that the player is now moving forward and turning right:
4
1
Or, to teleport to 100x200:
6#100#200
Where # is the parameter delimiter.
The socket connection would be connected to the player identifier, so that no identifier has to be broadcasted with the protocol to know what player the message belongs to.
Of course all data would be validated server side, but that is a different subject.
Now, this seems pretty efficient to me, only 2 bytes to inform the server that I am moving forward and turning right.
However, most "professional" code snippets I saw seemed to be sending objects or xml commands. This seems to require a lot more server resources to me, doesn't it?
Is my unexperienced logic of why my text based protocol would be efficient flawed? Or what is the recommended protocol for real-time action multiplayer games?
I want to setup a protocol that is as efficient as possible, because I do not want to use multiple clusters/servers to cover excessive amounts of bandwidth for my 2D multiplayer game, and to safe synchronization problems and hassle.
However, most "professional" code
snippets I saw seemed to be sending
objects or xml commands. This seems to
require a lot more server resources to
me, doesn't it?
Is my unexperienced logic of why my
text based protocol would be efficient
flawed? Or what is the recommended
protocol for real-time action
multiplayer games?
Plain text is more expensive to send than a binary format containing the same information. For example, if you only send 1 byte, you can only send 10 different commands, digits 0 to 9. A binary format can send as many different commands as there are different values you can fit into a byte, ie. 256.
As such, although you are thinking of objects as being large, in actual fact they are almost always smaller than the plain text representation of that same object. Often they are as small as is possible without compression (and you can always add compression anyway).
The benefits of a plain text format are that they are easy to debug and understand. Unfortunately you lose those benefits if you put your own encoding in there (eg. reducing commands down to single digits instead of readable names). The downside is that the format is bigger, and that you have to write your own parser. XML formats eliminate the second problem, but they can't compete with a binary format for pure efficiency.
You are probably overthinking this issue at this stage, however. If you're only sending information about events such as the commands you mention above, bandwidth will not be a concern. It's broadcasting information about the game state that can get expensive - but even that can be mitigated by being careful who you send it to, and how frequently. I would recommend working with whatever format is easiest for now, as this will be the least of your problems. Just make sure that your code is always in a state where you can change the message writing and reading routines later if you need.
You need to be aware of the latency involved in sending your data. "Start turning"/"stop turning" will be less effective if the time between the receipt of those packets is different than the time between sending them.
I can't speak for all games, but when I've worked on this sort of code we'd send orientation and position information across the wire. That way the receiver could do smoothing and extrapolation (figure out where the object should be "now" based on data that I have that is already known to be old). Different games will want to send different data, but generally speaking you will need to figure out how to make the receiver's display of the data match the sender's, so you'll need to send data that is resilient in the face of networking problems.
Also, many games use UDP for this sort of data transfer instead of TCP. UDP is unreliable, so you may not get all of your packets. That means that "stop moving now" or "start moving now" may not be received in pairs. When coding on top of UDP then it's even more important to send "this is the state right now" every so often so that clients get ample opportunity to sync up.
The common way is to use a binary format, not text, not xml. So with only one byte you can represent one of 256 different commands.
Also use UDP and not TCP. The game will be a lot more responsive with UDP in case of packet loss. In case of packet loss you can still extrapolate the movements. With each packet send a packet number so that the server knows when the command was sent.
I highly recommend that you download the Quake source code where you can learn more about network programming in modern multiplayer games. It's really easy to read and understand.
edit:
I almost forgot..
Google's Protocol Buffers can be of great help when sending complex data structures.
I thought I would give my two cents and provide a practical application to what is being referred to as Binary Serialization. The concept is actually incredibly simple, yet only seems complicated on the outside.
You can actually send XMLs and have a server that processes the data within the XML to different functions within the server itself. You can also just send the server a single number that is stored within the server as a variable. After that, it can process the rest of the data and choose the correct course of actions.
As an example, some rough code:
private const MOVE_RIGHT:int = 0;
private const MOVE_LEFT:int = 1;
private const MOVE_UP:int = 2;
private const MOVE_DOWN:int = 3;
function processData(e:event.data)
{
switch (e)
{
case MOVE_RIGHT:
//move the clients player to the right
case MOVE_LEFT:
//move the clients player to the left
case MOVE_UP:
//move the clients player to the up
case MOVE_DOWN:
//move the clients player to the down
}
}
This would be a very simple example, and would need to be modified but as you can see you merely just store the variables encoded with whole numbers that you transmit in strings of numbers. You can parse these and create headers of information to organize them into different sections of data that needs to be transmitted.
Also, it is better to do a UDP setup for games because just missing a packet should NOT halter the gaming experience, but instead should be able to handle it client-side AND server-side.