Hi,
After the development kit for the QCA4020 arrived, I was excited to try out the new module and see if it could replace the QCA4004. However, I cannot find any way of getting Radiotap headers in WiFi promiscuous operation, nor any other way of obtaining per-packet RSSI information. The older QCA4004 presented all this information in an easily accessible manner. Why is the QCA4020 worse in this regard? Is it a firmware issue? Can you provide a proper firmware image which works as it should? Without proper radio information, the QCA4020 does not fulfill our needs.
OK. Will add this support soon.
Thanks
That is great news. Thank you for a quick reply. Could you please elaborate slightly regarding when? Is it a question of weeks or months?
Hi ,
Can you provide some more use case of your requirement realted to radiotap header.
Hi,
It is for indoor positioning and asset tracking. We determine the distance to a transmitter based on the RSSI indicator at the RX antenna by listening for probe requests in promiscuous mode.
Hi,
Do you have an idea about a timeline for this?
Regards
Hi ,
I think you need only per-packet RSSI information? Right.
Can you please confirm ?
Regards
Jyotiranjan
Yes, per-packet RSSI is what is strictly necessary.
The rest of the information (MAC of originating device, channel, frame type and subtype) should already be present in the 802.11-header or inferrable.
If possible, Channel State Information (CSI) would also be useful, e.g. knowing if a received signal has been reflected, average gain, actual frequency (could be off-center), etc., which makes for more accurate estimation of both distance and direction to an originating device.
In short, the more low-level radio information available, the better.
Hi ,
For now is it Ok only RSSI info. ??
Hello,
Yes, for now RSSI info should suffice.
Received channel number is also needed if the hardware can return frames received on a channel _after_ a channel change was requested:
1. Suppose the chip is set to monitor channel 36. We know the receiving channel, since we set it and stored it in memory. This variable can be read from the rx monitor callback and combined with the RSSI information to calculate the distance between transmitter and receiver.
2. Software requests a switch to channel 6 and updates the receiving channel variable. Can there be frames previously received on channel 36 which have not yet been reported to the monitor callback? If so, the software will wrongly believe those came from channel 6, instead of 36. If this can happen, we also need the firmware to report which channel each monitored frame was received on. If this cannot happen, everything is good as-is.
Thank you.
Hi ,
Do you change channel frequently? I just think for below scenario in this case??
I am just afraid that if the packet is recieved on channel 6 and report to host, however, the customer change channel to 36, then they process that packet in their application. In those case, they may treat this packet from channel 36, not channel 6
Please help to answer .
Hi,
We currently do not change channel frequently, so it should not be a major problem in practice.
The mentioned scenario would best be avoided by also including received channel in the packet information.