CC3235MODS: CC3235MOD transceiver mode

The thread was assigned to one of our experts. Please expect response early next week.

Hi,

How do you open the socket? I assume with AF_RF but what about the type?

sl_Socket(SL_AF_RF ,SL_SOCK_RAW or SL_SOCK_DGRAM? 

Generally, RAW sockets are datagram oriented (packet boundary) so very similar to UDP and not TCP. So I do expect to get a single packet on each call to sl_Recv().

The way it works is that each call to sl_Recv() would fetch a packet from the NWP (if it is already there). Notice that if you did not configure any filter, the device is in promiscuous mode, meaning it gets every packet as if it was a sniffer.

Again, there should not be any padding and if you call with size of 15xx, you should get the packet size.

Please let me know how you opened the socket on both transmitting and receiving side.

Shlomi

Hi, Shlomi Itzhak,

Many thanks for the comments,

When I open a socket:
i32Soc = sl_Socket(SL_AF_RF ,SL_SOCK_DGRAM, rfchannel);

When I send an application frame,
NumOfBytes =sl_Send(i32Soc,buff,sizeof(buff),SL_WLAN_RAW_RF_TX_PARAMS(rfchannel,rfrate,rftxpower,rfpreamble));

When I receive,
NumOfBytes = sl_Recv(i32Soc, buf2,1536,0);
with the following options:
Status = sl_SetSockOpt(i32Soc,SL_SOL_PHY_OPT, SL_SO_PHY_RATE, &rfrate, sizeof(rfrate));
Status = sl_SetSockOpt(i32Soc, SL_SOL_PHY_OPT, SL_SO_PHY_PREAMBLE, &rfpreamble, sizeof(rfpreamble));
Status = sl_SetSockOpt(i32Soc,SL_SOL_SOCKET,SL_SO_NONBLOCKING,(_u8*)&enableOption,sizeof(enableOption));

I also use an Rx filter to filter out MAC address which I don't want to get.

Looking forward to hearing from you soon.

J.Y. Kim

Hi,

I tested it a while ago and from what I recall, each time I call sl_Recv() with full 1500 bytes buffer (assuming I do not know what size I am expecting), I always get the right size. There is no padding of any kind or partial packets.

What exactly are you filtering?

Is it possible you get packets you thought you filtered out but you got those to the host?

What servicepack are you using?

Shlomi

Hi,

As for the filtering, I use:
Rule.CompareFunc = SL_WLAN_RX_FILTER_CMP_FUNC_NOT_EQUAL_TO;
Rule.Field = SL_WLAN_RX_FILTER_HFIELD_MAC_DST_ADDR;
Action.Type = SL_WLAN_RX_FILTER_ACTION_DROP;

I may drop this filtering as there seems to be no distinctive improvement

When I call sl_Recv() and display as is without parsing, some times I got a data stream which
was not sent by any peer side. My intention was to filter out those invalid packets.

As for the SDK, I'm using simplelink_cc32xx_sdk_5_20_00_06

According to your previous notes,
if I select SL_SOCK_RAW instead of SL_SOCK_DGRAM and no Rx filtering,
then do you think NWP won't hold data and process transmission?

J.Y. Kim

Hi,

the socket is opened OK on your side. Please don't use RAW socket as the only difference is that the device does not respect the air with RAW, meaning it would not respect other clients before accessing the air (and thus probability of collisions is high).

If you say that the filter does not seem to work, this may explain the data you get.

Can you post the code snippet of how you implemented the filter?

Shlomi

Hi, Shlomi,

The issue that the sender always sends 1536 bytes is resolved. 

//NumOfBytes = sl_Send(i32Soc,buff,sizeof(buff),SL_WLAN_RAW_RF_TX_PARAMS(rfchannel,rfrate,rftxpower,rfpreamble));
NumOfBytes = sl_Send(i32Soc,buff,tt1,SL_WLAN_RAW_RF_TX_PARAMS(rfchannel,rfrate,rftxpower,rfpreamble));//jy 2022.3.9

I used the sample code which has buffer size of 1536. When I use actual size, tt1, this problem is resolved. 

Still, I have an issue on receiver side. The NWP doesn't upload the received data immediately.

I also use the sample code:

NumOfBytes = sl_Recv(i32Soc, buf2,1536,0);

If I change 1536 to a smaller number, does it help the problem? 

BRs,

J.Y.

Hi,

yes, on the send side you need to send exactly the amount of data in your buffer, otherwise you get some leftovers.

on the receive side, you can read the maximum 1536 into your buffer and should get only the size that you sent. So it wouldn't help your issue if you decrease the size on the RX side.

what do you mean exactly by not getting the data immediately? can you elaborate?

do you get only a partial packet? two packets concatenated? get the packet OK but with a delay?

Shlomi

Hi, Shlomi,

When I send, for example, 5 application data frames or packets to the peer device, 

the peer device immediately uploads only 4 packets, and the last one comes up later

either

1. when a garbage data is received and the garbage data and the last one comes up in sequence.

2. when the host of the receiver downloads a data frame for transmission.

In other words, when I send a single  packet to the peer device, the peer device doesn't upload the received packet immediately.

I need the NWP to reply to sl_Recv(i32Soc, buf2,1536,0) function immediately once it receives a packet. 

JY.

Hi,

I do not see such a behavior on my side.

so if you get to this state where the receiver side is not able to receive the packet and then send a single packet again from the transmission side, would you get the previous packet and gets stuck on the new one?

are you working in blocking mode socket?

Regards,

Shlomi

Hi,

Yes. 

Once a transmission side sends a packet, then the receiver seems to receive it but it doesn't upload it even though I call sl_Recv().

It looks like that the NWP holds the received packet in its buffer and doesn't reply immediately.

I'm using non-blocking mode. And I call sl_Recv() at main() loop, so if there is no uart data then it calls sl_Recv() repeatedly.