I have to reverse engineer mobile radio terminal over air polling responses to recover location data. I can recover the bit-stream using gnu radio stack overflow link
but cannot get the clock recovery module to work. Data is 1200 Baud, CRC16 so can move onto decoding once I can sink data to a file.
Related
I am writing a real-time game client. It works great on desktop, but as I come to implement it on iOS, the packets seems to cluster together and only send ever half second to 1 second which yields a very jumpy experience.
I am using the low level sys/socket library so a send simply looks like
send(this->sock, bytes, byteslength, 0)
As I said, this does not have this behavior on a desktop system, but I assume there is some sort of power saving logic going on here that wants to cluster the data into a single packet instead of sending the packet as soon as send is called. Certainly there must be a way to force the fast send.
When I try to send an object with multiple images(converted to string using Base64) as STREAM type, from the onPayloadTransferUpdate() method, I can see "Failure" result and the devices(tested only when 2 devices are connected) automatically disconnect after that. Is Google Nearby connections not the right option to send large bytes?
Nearby Connections should be able to handle that. There's no explicit size limit on STREAM payloads.
I would suggest chunking the bytes (eg. send a couple KB at a time) and seeing if that helps. You can get into weird situations when you send entire files at once because it loads the bytes into memory twice (once inside your app, and once inside the Nearby process) which can cause out of memory errors. Binder, the interprocess communication layer on Android, also has a limited buffer to send data between processes.
You can also save it as a temporary file and send it as a FILE payload, in which case we will handle the chunking for you.
Disclaimer: I work on Nearby Connections.
1) You don't need to Base64-encode the data for the sake of Nearby Connections -- your STREAM can have raw binary data, and that'll work just fine.
2) How big is this data you're sending, and at what byte offset (you can see this in the PayloadTransferUpdate you get with Status.ERROR) does it fail at? It sounds like your devices are just getting disconnected.
3) What Strategy are you using?
4) If you still have discovery ongoing (i.e. you haven't called stopDiscovery()), try stopping that and then sending your Payload -- discovery is a heavyweight operation that can make it hard to reliably maintain connections between devices for long intervals.
Every tutorial about Apache Flume gives example of "logs getting continuously generated" as the example.
I am curious if Flume works only on text data or it can also work with streaming data like audio, video, electronic sensor inputs ?
Because irrespective of data type it is all bytes array.
It is designed for text data streaming. It is possible to provide a schema definition for text data, so that the consumer of the data can process it after receiving it. Consumer of data can scale horizontally with the increasing size of data, still making use of commodity hardware(moderate cores/ RAM). However for binary data the reconstruction and parsing would be a heavily resource intensive operation.
I am a complete CAN bus newbie. I'm hoping someone with CAN experience can point me in the right direction. I was given a Vector VN1610 USB to CAN adapter and a Continental ARS-308 radar sensor. The goal is to read some velocity and distance information from the sensor. Right now I am just trying to see any data but all I get are messages with an id of 0 or 0x80000000. The data payloads all report as 8 bytes of 0.
What Works
I have been able to use the sample .NET code provided and set up the VN1610. The ARS-308 has a single CAN channel so in the Vector Hardware Config for my application I just map "CAN 1" to VN16101 Channel 1. (I leave CAN 2 unassigned) I then assume I use that one channel for both transmit and receive. The code reports that the channel sets up an activates and no errors are reported.
I then have a thread looking for incoming messages. If I don't debug out the two IDs mentioned above I can actually process all of them and then I get XL_ERR_QUEUE_IS_EMPTY messages. So it looks like its all working, I'm just not getting any real data.
What Doesn't
I would think a slew of data messages in the 0x200 - 0x702 range would be coming in for the Continental ARS device. Now I'm more used to ethernet type protocols where I would send a command and then read a response. None of my docs talk about how CAN works so I am ASSUMING that in CAN the device just sends data. I certainly can't find any commands that tell the device to send me the particular msg ID I'm interested in.
Am I missing some basic CAN configuration step that informs the device it should start sending data? Any suggestions at all would be appreciated.
If it matters I'm writing in VS2013, .NET on a Win 7 64 Ultimate machine.
The answer is No. It turns out that CAN devices will indeed just start streaming out messages when you turn them on (well at least this one does). The messages with ids of 0x0 and 0x8000000 are bogus. Even with the radar sensor turned off I continued to see those messages.
It turns out I had a hardware problem. The CAN bus requires a 120 Ohm resistor which was installed. The problem was when the shell was put back on the cable the resistor got cracked. Once we repaired this, everything started working as expected.
I have a question regarding the synchronization of 2 Directsound streams.
To record and play sound I currently use Portaudio to open 2 Directsound streams.
There are 2 callback functions which are called every time the input buffer is filled and the output buffer needs data.
Now here`s my problem...
The input stream is running at 48kHz samplerate (#1024 samples). The output stream is running at 192kHz samplerate (#4096 samples). Every time the input buffer is filled and the callback is called I do some DSP and after that I convert the result to 192kHz. The output stream takes the result and outputs the data. Now the 2 streams are running completely out of sync.
I have looked through the entire Portaudio API but I cant`t find a sync option to lock the 2 streams together.
Is there any way to lock 2 Directsound streams? I really need 48kHz input and 192kHz output.
Br,
Vincent Bruinink.
The thing is that you can't really open two streams "at the same time", nor can you open two devices (or even one device at two different sample rates) and expect them to stay truly in sync, even if they were, at one time, in sync. To understand why, you may want to read something about how audio works on a computer. You may also want to read this document, which is specific to PortAudio.
As an alternative, you may want to consider opening a single device in a single stream and using software sample-rate conversion.