Hi for my application I need to send 1 byte of data each 200 us, after trying different configurations of the packet handler I realized that this is not possible with this approach. So I changed to direct mode and making the packet configuration directly in the MCU, I have had promissing result so far. The 1 way link is no problem, I used the WDS to generate a direct mode RX config file and a direct mode TX config file using the examples and it works! now for my application I need to change from direct mode TX to direct mode RX and vice versa. In order to do so I could just  load the configuration files once again but unfurtunatly this takes too long when loading the RX configuration. I compared both configuration files and determined what is the difference between both in order to make 2 subconfiguration files and load just the neccessary parameters but this didn't work as when I do this the data rate changes from 40kbps to 3.6 kbps. What should I do in order to change from direct mode TX to direct mode RX on the fly?

 

Thanks in advance, I included both configuration files, a configuration file that has the parameters of both TX and RX combined and the bare minumum configurations that I load in order to change from tx to rx and from rx to tx. I'm using the si4463 radio

Do you mean the TX side problem solved with direct mode and now you are trying to receive that transmission?

In direct mode we can receive the data stream that was generated in the transmisor side with little delay between them, but in order to recover the message that generated this data stream we would have to include another microprocessor just for this task or a shift register or other dedicated hardware for this. We can totally avoid this if we can make the radio packet handler able to process the data stream but as can be seen in the first picture we still aren't capable of doing this, in this regard I wanted to ask for more information on the Any (transitioning) pattern configuration, the tip says that  "Tip: treat the preamble and the sync word of the incoming packet as one field, reserve the 1st byte for receiver settling and use the rest for sync word detection." this should be done in the sync word configuration? Should the first byte be AA (10101010)?  how many errors bit should be allowed?  How much faster would the packet handler rearming be? Is there any form to calculate this based on the packet configuration?

TLDR: specialized hardware is needed to make this work in direct mode, do you have more info on the any transitioning patter?

What is finally your transmitted packet structure that you are trying to receive? 

We are still using the one posted in the beginning 4 preamble 1 sync 1 payload, no CRC or anything else. We are definitely open to use a different package configuration, the only thing is that we need at least 1 byte of payload.

As an alternative of direct TX, what cycle time could you achieve with TX_STATE as TXCOMPLETE_STATE?

280 us was the least time that we could achieve, we managed to use the direct mode to keep sending preamble and each 200us the sync word and the payload.

How much delay can you tolerate to get the data byte on the RX side after it was created on the TX side?

up to 1ms of delay is fine.

 

Thanks for your answers!

Felipe

 

 

 

 

Hi,

Do you mean the TX side problem solved with direct mode and now you are trying to receive that transmission?

What is finally your transmitted packet structure that you are trying to receive? 

Yes, EZR32 has exact same Si446x revC2 radio.

As an alternative of direct TX, what cycle time could you achieve with TX_STATE as TXCOMPLETE_STATE?

Hi,

Do you mean the TX side problem solved with direct mode and now you are trying to receive that transmission?

What is finally your transmitted packet structure that you are trying to receive? 

Yes, EZR32 has exact same Si446x revC2 radio.

As an alternative of direct TX, what cycle time could you achieve with TX_STATE as TXCOMPLETE_STATE?

Hi I have this package installled I think, look at the picture bellow, but still no examples.

Hi! I bought the SLWSTK6241A  ezr32hg radio kit and installed the simplicity studio 5 and could not find any examples, and although it recognices the hardware that I have, when I try to see the available examples a message appears saying " There are no examples available based upon your selections for Board, Device, SDK, IDE, and Toolchain.
Please use the back button to make changes to these options " Is there any extra software that I need? should I use simplicity studio v4 instead?

 

Thanks

Felipe

Hi, I read the help in the wds but there is no much information. Is there any more detailed information on this topic? I mean Shorter or zero preamble. Also we have some ezr32hg dev kits, of what I read I think that this chip is just an m0 arm processor but with the very same radio included, should I expect this very same problems? or is there any optimization in the time that it takes to rearm the packet handler or so?

Also in the spirit of the first question what would be your recomendation to achieve one packet of 1 byte payload each 200 us? In your expert opinion is the direct mode the only way to achieve this?

 

thanks!

Hi I followed the synchronous direct mode approach proposed in the first link and I was able to send packets each ~200us but in the RX radio one every two packets is not detected as can be seen in the picture that I uploaded. In the figure the TX data is shown on top, the middle is the sync word flag that is being measured in a GPIO, the bottom curve is the RX data after synchronisation thats being also measured through a GPIO in the RX radio, in red is the desynchronization that happens once every two packets sent. The TX radio is configured to comeback to RX using the   RXVALID_STATE[3:0] =8 " RX state (briefly exit and re-enter RX state to re-arm for acquisition of another packet). " is this what is causing the error once every two packets? I'm surely going to try it but I will ask in case that you can add more information, if i select  RXVALID_STATE[3:0] as 0      "Remain in RX state (but do not re-arm to acquire another packet)" will this cause to add the next bytes after the first transmision directly to the fifo or what will it be the effect? Thanks again

Thanks for your answer, the gap that you artre talking about is the 58us that comes from going back to the tx tune state? in the API documentation there is no TX_STATE in the  TXCOMPLETE_STATE configuration byte, in order to comeback to the TX_STATE should I choose TX_TUNE=5 as the  TXCOMPLETE_STATE configuration byte? what happens if I use RESERVED=7 as the TXCOMPLETE_STATE, in the document AN625 it says that by doing this the next state will be TX_STATE.

 

Thanks for your help!

Hi, I've been reading the documentation and I think I can make the chip work as I want, the only thing I need is to keep in the TX_STATE. My plan is to use a packet configuration with only one byte of payload and manually form the packets in the FIFO, I will use the  the TX_FIFO_ALMOST_EMPTY interrupt to keep filling the FIFO with preamble bytes until I need to send information in wich case I will just load the FIFO with the sync byte and the information byte. Upon reading the API i found that one has to specify the state that the radio will go after the completition of the packet with the  TXCOMPLETE_STATE[3:0] register, the only trouble is that it does not have any option to keep in the TX_STATE. If I doesn't spedify a TX_LEN will it keep sending data until the FIFO is empty or will it just send one?

 

Thanks in advance for your help!