2009-11-21

This is SO frustrating. I spent the day rewriting the CUL firmware so it sends the USB data more directly via the hardware, bypassing the higher level USB print functions. To no use it seems. The received pulse lengths still vary way too much, so the USB overhead was not the problem. The problem seems to be worse for short pulses, which makes CUL useless for at least the NexaL protocol.

I may have to release CUL-support with only sending enabled, I think it will only annoy people if I include reception and it works bad...

This feels like a lot of time wasted.

6 comments:

  1. Hej.
    Jag hoppas verkligen att du får till det med CUL support. Tills vidare kör jag med din UPM lösning (UPM har bytt namn till ESIC hos CO).
    Jag har dock problem med att fånga NexaL koder. Det rycktas på annat forum att du har nyare versioner som fungerar bättre. Går det att få tillgång till denna? Ditt program är en viktig del i mitt blandhem med FS20 och Nexa.

    ReplyDelete
  2. Hi David,
    I am afraid you will have to keep using the UPM (ESIC) solution for a while. I have not managed to get the CUL reception to a decent level. Hopefully it will work as a transmitter at least. I am however interested if you have problems with the current NexaL-support. All feedback I can get there is good so I can tune the decoders. I will probably release the new ProtocolDecoder-program first and then a new version of the NetHomeServer.

    /Stefan

    ReplyDelete
  3. Hi Stefan
    How can I send you the feedback?

    Gott NexaL working for some transmiter, not all :(
    /David

    ReplyDelete
  4. My mail address is actually on the site, at the bottom of the page http://wiki.nethome.nu/doku.php/nethomeservercurrentstate

    But it is somewhat obscured, so the spam bots should not find it too easy - hopefully you can figure it out ;-)

    /Stefan

    ReplyDelete
  5. Do you know if the problem is in the CC1101 transceiver or in the time capture? I think I saw a remark somewhere that the CUL original firmware configured the CC1101 for 1 kb/s...

    /Tord

    ReplyDelete
  6. I suspect the receiver hardware is not really optimized for the primitive OOK-encoding these protocols use. I have reprogrammed the receiver for higher data rate and tried a lot of different settings of RX filter bandwidths and AGC-settings according to the documentation and SmartRFStudio, but not managed to get it even close to as good as the UPM-receiver

    ReplyDelete