How is Forward Error Correction implemented in Unet audio, and what approach should be used to work on the existing algorithm or to add a new FEC technique to the Unetstack?
The Unet audio community version implements a ½ rate convolution FEC, which can be enabled or disabled using phy[1].fec or phy[2].fec parameters. If you disable the FEC and there are any errors in the received frame, the CRC check will likely fail, and you'll get a BadFrameNtf instead of a RxFrameNtf. The BadFrameNtf message will have the erroneous bits available as data. If you want to implement your own FEC, you can use these as hard decisions from the PHY layer and do your decoding.
So, to implement your own FEC:
Disable the default FEC on transmit and receive modems (phy[2].fec = 0).
Create your own uncoded frame by including source address, destination address, and protocol number along with your data bits. Compute a CRC and include it in the frame.
FEC encode your uncoded frame and send the encoded bits using a TxRawFrameReq from the transmitter. The "raw" frame request tells UnetStack not to add its default headers.
Receive the corresponding BadFrameNtf on the receiver and extract the received bits from data field.
FEC decode the received bits to yield the uncoded received frame.
Check CRC on the uncoded receive frame. If that passes, then extract the source address, destination address, protocol number and your data from the uncoded received frame.
If you want the rest of the stack to process this as if it came from PHY, you can send a RxFrameNtf with relevant fields filled in and send it on the topic(phy).
Related
I have a NDIS 6 filter driver working on Windows Vista and later systems.
I have bound it below NativeWiFi Filter so I can see 802.11 packets instead of fake Ethernet packets.
And I have set the NDIS_PACKET_TYPE_802_11_RAW_DATA and NDIS_PACKET_TYPE_802_11_RAW_MGMT in the packet filter based on: https://msdn.microsoft.com/en-us/library/windows/hardware/ff554833(v=vs.85).aspx, so I can receive the Raw 802.11 Packets indications from the miniport.
Then I switched my wireless adapter to Monitor Mode.
By now my filter driver can receive all the 802.11 control and management packets.
My question is how to determine whether a 802.11 raw packet has FCS (frame check sequence, 4bytes) in my driver?
I'm asking this because i'm adding Radiotap header (http://radiotap.org/) to the packets and radiotap has a field called Flags that specified whether the 802.11 packet has a FCS or not.
My experiment with my laptop with a wireless adapter Qualcomm Atheros AR9485WB-EG Wireless Network Adapter shows that Beacon and Reassociation Response packets have FCS and all other 802.11 packets don't have one. And the wrong Flags in the radiotap header will cause Wireshark to show Malformed Packet for those packets. This is why I need to determine the availability of FCS in my driver.
My code is like below, and I want to know how to write the if condition.
// [Radiotap] "Flags" field.
if (TRUE) // The packet doesn't have FCS. We always have no FCS for all packets currently.
{
pRadiotapHeader->it_present |= BIT(IEEE80211_RADIOTAP_FLAGS);
*((UCHAR*)Dot11RadiotapHeader + cur) = 0x0; // 0x0: none
cur += sizeof(UCHAR) / sizeof(UCHAR);
}
else // The packet has FCS.
{
pRadiotapHeader->it_present |= BIT(IEEE80211_RADIOTAP_FLAGS);
*((UCHAR*)Dot11RadiotapHeader + cur) = IEEE80211_RADIOTAP_F_FCS; // 0x10: frame includes FCS
// FCS check fails.
if ((pwInfo->uReceiveFlags & DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE) == DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE)
{
*((UCHAR*)Dot11RadiotapHeader + cur) |= IEEE80211_RADIOTAP_F_BADFCS; // 0x40: frame failed FCS check
}
cur += sizeof(UCHAR) / sizeof(UCHAR);
}
Any methods? Thanks!
My experiment with my laptop with a wireless adapter Qualcomm Atheros AR9485WB-EG Wireless Network Adapter shows that Beacon and Reassociation Response packets have FCS and all other 802.11 packets don't have one.
No, it doesn't. When I looked at the same capture, and forced the "FCS at end" flag on, I found that a LOT of frames other than those frames had an FCS that Wireshark reported as valid. Do NOT assume that, just because a frame didn't show a "Malformed frame" error, it didn't have an FCS; the "Malformed frame" errors are due to Wireshark thinking the FCS is frame data, and trying to dissect items larger than the 4 bytes of the FCS. For data frames, the 802.11 dissector doesn't dissect the payload, and if the payload has a length field of its own, as IPv4 and IPv6 frames do, that length will be used, and the FCS will be treated as extra data after the payload and not cause a "Malformed frame" error.
What you should try is to check whether uReceiveFlags has DOT11_RECV_FLAG_RAW_PACKET set and, if so, assume the frame has an FCS, otherwise assume it doesn't.
And remember that, in monitor mode, frames that couldn't be completely received may still be provided to the host, so some "Malformed frame" errors in monitor mode may be due to, for example, the frame being cut short by the radio, so don't assume that a "Malformed frame" error means that the frame shouldn't have had the "FCS at end" flag set.
I have a working ble device with android .
it sends and receives data finely through the Android app.
But Now My Problem is I want to send Some Audio HEX files to my BLE Device.
And its larger Than 20 bytes.
How Can i send such a data to a BLE Device. ??
For send data upper than 20bytes, you need to change the MTU-exchange.
To API LEVEL 21, you can use requestMtu (Android Developer), it negotiates with the peripherical device and you can define until 512 bytes.
The MTU value is defined in peripherical side. Remember the data size that you can send is MTU-3 bytes.
For API LEVEL less than 21, the MTU is pre-defined and you can't modify.
The size limit can be different than 20, I suppose the MTU size is negotiable, thus you should never hard code any assumptions on sizes.
to get it right, firstly inside the onCharacteristicReadRequest you simple check the offset and give all data from that point to the response.
then in onDescriptorWriteRequest, if the preparedWrite is set to true, you need to store the values you get, and combine them once you get onExecuteWrite() called.
Example implementation available at: https://github.com/DrJukka/BLETestStuff/blob/master/MyBLETest/app/src/main/java/org/thaliproject/p2p/mybletest/BLEAdvertiserLollipop.java
One way you could proceed is to split the audio hex in to small pieces of data .You can use Serial Port Profile to send these chunks of data .Once all data are received you can combine and store using some merging algorithm (google it) and later revert it back to an audio hex file .
This question is about firmware for an 8 outgoing channels IR transmitter. It is a micro-controller board with 8 IR leds. The goal is to have a transmitter capable of sending streams of data using one or multiple channels.
The data is delivered to the board over UART and then transmitted over one or multiple channels.
My transmitter circuit is faster than the UART, so no flow control is required.
Currently I have the channel fixed in the firmware, so each byte from the UART is transmitted directly. This means that there is no way to set the desired channel over UART, which is what I want.
Of course, the easiest solution is to append the data byte with a control byte in which each bit represents one channel. This had the advantage that each byte can be routed to one or more channels, but of course increases overhead dramatically.
Because of the stream type of transmission, I am trying to avoid a length field in my transmitter.
My research work is in the network stack on top of this.
My question is if there are schemes or good practices to solve this. I expect that similar problems are in robotics, where sensor data streams cross control signals all the time, but I could not find a simple and elegant solution.
I generally use the SLIP transmission protocol in my projects. It is very fast, easy to implement, and works very good to frame ANY packet you want.
http://www.tcpipguide.com/free/t_SerialLineInternetProtocolSLIP.htm
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=slip%20protocol
Basically, you feed each byte to be transmitted or received into a function that uses 0xC0 as both a header and a footer. Since 0xC0 is a valid byte in the data packet that you could be sending a few transformations are made to data bytes of 0xC0 in order to GUARANTEED that 0xC0 will only be a header and footer.
Then using the reverse algorithm on the other side you can frame the incoming data and look for 0xC0 twice in the right order. This signifies a full packet that will can be buffered up and flagged for main cpu processing.
The SLIP will guarantee the right framing of the packet.
Then it is up to you to define your own packet format that exists as the data field inside the SLIP packet has correctly framed the packet.
I often do the following...
<0xC0> ...<0xC0>
Use different opcodes for your different channels. You can easily add another layer with Acknowledgements if you want.
Seems like the only sensible solution is to create a carrier protocol for the UART data. You might want this anyway, since UART has poor immunity to EMI. You can make it more reliable by including a CRC check to the protocol. (Please note that the built-in error handling of UART through start/stop/parity is very naive and very much outdated since the mid 70s or so.)
Typically these protocols go like <sync token> <header> <data> <checksum>, where the header may contain a data length and the data can then be of variable length.
Probably not an option at this point, but SPI would have been a much more pleasant interface to work with for this. You could then have one shift register per 8 IR diodes and select channel through the SPI slave select through some MUX/DEMUX circuit. Everything would work synchronously and no carrier protocol is needed. And it would completely remove the need for a MCU between the data sender and the diodes.
I am developing a device that takes a picture and transfers that picture to desktop computer receiver wirelessly through radio waves. On the receiver end, I am using C and fwrite() to rebuild the image file sent by split packets of data. Receiving a packet executes:
fwrite(&data[3], size, 1, filename);
data[3] is an unsigned 8 bit integer, data type u08.
I confirm that wired file transfer works. If the transmitter and receiver are directly connected, there is no problem.
However, the radio signal is not strong enough to guarantee that all packets will be received. In my testing, lost in transmission packets are common. If even one packet is lost, the image file becomes corrupt. Received rate is roughly 85%.
Every packet is numbered. If the received packet number is greater than the expected packet number, then the receiver knows that a packet has been dropped.
My solution is to loop and replace missing packets with a default packet while incrementing the expected packet number counter. Basically, I plan to fill lost pixels with black pixels, using the received packets to create the most completely picture possible. I do not know how to do this. I tried simply setting data[3] to 0 if the received packet number and expected packet number do not match up, but this did not work.
I welcome other proposed solutions.
U have not mentioned the image format. If you are sending crude RGB image then setting to zero thing should work but if you are playing with compressed images like jpeg and you have lost the header packets having information about block sizes or tables used for entropy encoding there is no way to get the image back.
How do you identify missing UDP frames in a custom Wireshark dissector?
I have written a custom dissector for the CQS feed (reference page). One of our servers gaps when receiving this feed. According to Wireshark, some UDP frames are never received. I know that the frames were sent because all of our other servers are gap-free.
A CQS frame consists of multiple messages, each having its own sequence number. My custom dissector provides the following data to Wireshark:
cqs.frame_gaps - the number of gaps within a UDP frame (always zero)
cqs.frame_first_seq - the first sequence number in a UDP frame
cqs.frame_expected_seq - the first sequence number expected in the next UDP frame
cqs.frame_msg_count - the number of messages in this UDP frame
And I am displaying each of these values in custom columns, as shown in this screenshot:
I tried adding code to my dissector that simply saves the last-processed sequence number (as a local static), and flags gaps when the dissector processes a frame where current_sequence != (previous_sequence + 1). This did not work because the dissector can be called in random-access order, depending on where you click in the GUI. So you could process frame 10, then frame 15, then frame 11, etc.
Is there any way for my dissector to know if the frame that came before it (or the frame that follows) is missing?
The dissector is written in C.
(See also a companion post on serverfault.com)
You should keep in mind that Wireshark does dissection multiple times. First time it dissects packets in strict order when you load file. Then it calls dissectors when you scroll packet_tree_view or select a packet to build it's tree.
You can check if a dissector is called fot ther first time:
if (PINFO_IS_VISITED(pinfo)) { ... };
Your dissector should behave differently for the first and for the next dissections.
At first dissection you have to store some information for each packet (in a hash table for example) as it's sequence number and if it is out of order. You will need it to build packet tree properly when you are called second time.
I don't konw if you can peek into previous or following frames, but when Wireshark is loading a tcpdump it will call your dissector on each of the frames in order. So I could add a static local variable which is an array or hash table and simply store your values in there. Then your dissector can check that array for previous and following frames and do its analysis.
You should look at that pinfo vairable, that's one of the function arguments for information about the frame number, IP information etc.