Jump to content

Paal

Members
  • Content Count

    4
  • Joined

  • Last visited

  • Days Won

    1

Paal last won the day on October 2 2016

Paal had the most liked content!

About Paal

  • Rank
    Noob Class

Profile Information

  • Location
    Norway
  • Interests
    Analog design
    IoT
    Home automation
    Anything RC
  1. Just a quick update on the issues I described above, if someone stumbles by I was able to trace down the cause for the crashes I had when the receiver was operating at its sensitivity level (weak signal). It was indeed related to the "packet length byte" associated with the data payload getting corrupted. After some poking around in the AIR library I found that that the CC1101 packet length configuration was set to 61 bytes. In my sketch I had only reserved 10 bytes in data memory for RX data, because I was only sending 10 bytes. My confusion around that was that with the AIR library, you specify in your sketch how many bytes you are receiving each time. I had set this value to 10, believing that the packet handling then would be done using this value. I was wrong, under the hood of the AIR library, it was still accepting packets up to 61 bytes long. So every time the lengt byte was corrupted to a value between 10 and 61, some other data was overwritten by junk (packets with lenght byte > 61 bytes is automatically discarded by the CC1101 packet handler with the AIR library). The simple fix was of course to increase the rxdata space to 61 bytes, I had a simple application and using the G2553 with enough RAM. Doing this, I got what seemed like a rock stable application even at an RF level where most of the packets was corrupted due to poor signal to noise ratio. Not terribly happy with the AIR library, but I guess it wasn't really made for tinkering too much, just running the example sketches as is... Edit: I see that the OP has made the same mistake as I did, he is only reserving 50 bytes in data memory for RX data. So his application will be more stable than mine, because its only packages with length between 50 and 61 that will crash his application.
  2. Hi, I've run into some problems with the Anaren library and the CC110L module. I have not had the time to dig very deep, but for me it crashes consistently when there are bit errors (e.g. due to interference or receiving near the sensitivity limit). When I had a very good link, it seems very stable. Could be related to what you see. Here's what I did, and something you could look into: Made a quick test mock up where I put the whole TX system (including batteries, no protruding wires!) in a closed tin can, and placed the RX in the next room, where I got about 50% packet error rate. The RX now crashed consistently every 10 - 20 packet, so I could debug. I got so far as to notice that the number of bytes returned by the Radio.receiverOn function by far exceeded the declared number of transmitted bytes. In my test program I transmitted 10 bytes, but when I started getting bit errors (the CRC was 0), the RX figured it received up to 10k bytes, and then crashed. This was as far as I got, but I suspect the huge number of received bytes messes up the data memory. Cheers, Paal
  3. Yes sir, that is what I'm hoping for. But would be nice to know for sure, new radio modules take forever to get from from Hongkong to Norway
  4. Hi guys, awsome forum, have been reading for a while, this is the first post. Although I'm no beginner with electronics in general (did analog IC design for more than 10 years), I'm definitely a beginner when it comes to embedded programming One thing that I've not been able to figure out is what happens to the GPIO's while the flash is being programmed, e.g. on a launchpad. Reason I'm asking is that I don't want to destroy any circuitry that is connected to the GPIO's and that could be driving these while the MSP is being programmed. Doing a lot SW iterations, guess I could call myself an agile developer Regards, Paal
×
×
  • Create New...