Announcement

Collapse
No announcement yet.

Rf300pd1

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rf300pd1

    I recently assembled 3 prototype boards with the RF300PD1 modules (through-hole versions). I am able to communicate with them wonderfully via USB-TTL serial adapters. However, with two or three units up and running simultaneously, Portal doesn't indicate more than the gateway unit being present. The default channel is 4. The default collision avoidance settings remain in their defualt state, and the mac addresses came from the vendor pre-programmed and reflect the number on the outer label. All MAC addresses are unique and original. All units are given unique names with common network IDs. I have tried them with and without rubber-duck antennas on the same table. Saturation related signal distortion has crossed my mind but I have never experienced it before with such a setup on any other system. I have been working with dozens of ZicM2410 for the past 18 months and have gotten pretty familiar with the SNAP systems but this has got me baffled. I have always had relatively good luck with the ZICs though I wish they had a through-hole version for ease of installation. And I tend to believe that 900Mhz may gain some range for my product line. So the RF300 seemed a logical choice. I will make an attempt to attach a schematic of the instrument board. There is a PIC processor shown on board but it is removed and makes no difference when it is in or out of it's socket. The RF300 is installed in headers on the board if that makes a difference. I know this has got to be something simple. The problem doesn't seem related to my code since they do not talk before I even load code into the modules, so I suspect default configuration, firmware, or else my board design. PLEASE HELP, I need to get these talking to move this project along.
    Attached Files
    Last edited by topherness54; 10-06-2011, 03:24 PM. Reason: grammar and punctuation

  • #2
    Rf300

    Do you have the antennas installed, the RF300 modules will not operate without them

    Comment


    • #3
      Antenna on RF300PD

      Yes, I meant to mention that. I have tried with and without.

      Comment


      • #4
        Topher,

        Do you have two protoboards or SNAPSticks from Synapse that you can use for a sanity check of the OTA comms? If you don't have these boards, you could turtle the modules and clip into pwr and ground (and UART if necessary).

        What does a sniffer show? Do you see any OTA traffic?
        sigpic
        Proven Solutions for the Internet of Things
        www.synapse-wireless.com

        Comment


        • #5
          One somewhat related item (that really doesn't apply to RF300s, more to embedded designs with the raw IC).

          By default this should be configured correctly for the RF300, but quoting the SNAP Ref Man...

          NV Parameter 64 is used on the Si100x.

          Bit 0x0001 – Indicates how the TX and RX registers are set in the hardware.

          When this bit is clear (set to 0), register 0x0C is set to 0x15, the receive state, and register 0x0D is set to 0x12, the transmit state. This is the appropriate setting for the RF30x SNAP Engine and any hardware similarly connected.

          When this bit is set (to 1), register 0x0C is set to 0x12 and register 0x0D is set to 0x15. This is the appropriate setting for the Silicon Labs EZRadio Pro 1000-TCB1 development board and any hardware similarly connected.

          If this bit is incorrectly set radio signal strength will be diminished, as will the radio’s ability to clearly receive signals. Users developing their own hardware according to the Silicon Labs demonstration board should be sure to set this feature bit.

          Resetting factory parameters does not modify this parameter.

          You can do a quick check of the vendor specific bits (NV 64)
          sigpic
          Proven Solutions for the Internet of Things
          www.synapse-wireless.com

          Comment


          • #6
            Rf300pd1

            When I originally polled the NV parameters I received "19" for parameter (11). Initial values upon reading brand new factory settings were "3" for (11) and "0" for (64). Strange thing is, NVparam 11 kept reverting to "19" after reboot while I also get a "?" when performing a loadNVParam with (11) entered into the argument field. Initial values upon reading brand new factory settings were "3" for (11) and "0" for (64).
            I will reassess this issue this evening and post the result late tonight or early tomorrow. Could someone please post verbatim what to enter into the NV parameter field when forcing the values through portal. I know how to modify the mac address with "\xAB\xCD\xEF\etc.".
            Any other ideas meanwhile would be greatly appreciated so that I can try them all when I get to working on the project later this evening.
            I can't help but wonder if there are some assumptions when we post something like "set this NV variable to 13". What I need to see at this point would be more like, "...set this NV variable to "\x0013h" <CR>" or "...set this NV variable to "\x13" <CR>" or something else to that degree of specificity in order to eliminate all doubt and variables since we are relatively new to the RF300/SNAP engine as most of our past R&D work has been with custom built prototype circuit boards and little or no reliance upon demo/eval kits (we just acquired our first SNAP eval/demo kit recently thanks to a very kind and generous loan from a well know vendor associated with Synapse-Wireless.

            Comment


            • #7
              RF300PD1 Sniffer

              I haven't done much with OTA sniffers yet believe it or not. I haven't had a real need to do so until now. Do you need a special board for that? I currently have a ZICM dungle (Basically the ZIC2410 inside a USB flash drive case with a TTL serial header for wire-wire programming). I use it as a ultra-portable gateway to monitor, debug, program, etc with our ZICM fleet. I believe it should be able to be reprogrammed to be an OTA sniffer, is that correct? Or can you perform that function without changing your underlying core SNAP OS installation?

              If monkeying around with the NV parameters mentioned in a post doesn't do the trick then I will try the OTA sniffer to see if anything seems afoul. If it gets to that point, I will post the results. I don't expect much based on previous link quality and energy readings performed.

              What about capacitors near pins on the module. I don't have a bunch of .1uF caps at all the Vcc pins, rather I have a couple large caps in line and load side of my regulator and generally have very little Vcc ripple when everything is where it should be. Are these entirely critical to install right next to the Vcc pins?

              Comment


              • #8
                sniffer

                The sniffer requires a RF module with the "sniffer" firmware loaded, then you simply launch the sniffer from the options menu.

                There is a sniffer manual under the help tab in Portal

                Comment


                • #9
                  Rf300pd1

                  I was able to load the sniffer firmware onto one of the 3 prototype boards early this week. When I ran the Sniffer software from Portal it saw nothing. The other prototype boards all currently have code installed that periodically sends sensor data via RPC dataLog to the Portal address. When wired in, this works fine. Without reviewing my code that I used to do this on our ZIC2410 units, shouldn't this travel the airwaves to try to get to the portal when not wired in? And as such, this should have provided something for the sniffer to see, regardless of where it was headed and what it was supposed to do. I loaded Sniffer firmware into the unit much the same way I would load Snappy firmware into a module. When restarting the module no longer responds to Portal gateway node queries but does reply to the Sniffer software connect query from the PC. So that part seems to be in order. Nothing on channel 4 though (or any other channel from what I can tell). When performing energyLevel and link quality queries I get results in the ballpark of 110, and 121 depending on which query I issue from the built in functions. It acts like the radios are just turned off completely while the MCU functions normally. I am running out of basic options here it feels like. I recall the ZICM2410 being similarly difficult at first but I have since conquered and mastered them. Are these really that different? Can someone at least confirm the make and model Silicone Labs MCU and RF unit hardware installed so that I can dig into the nuts and bolts.

                  Comment


                  • #10
                    Rf300pd1

                    I found this at the bottom of an obscure little document. This looks like it may be in line with what I am experiencing.
                    "
                    ERRATA
                    Notice of potential SM300 radio problem with SNAP 2.4.20 and earlier
                    If you turn the radio off and then back on using the rx() function in your scripts, then after invoking rx(True) your radio will experience poor performance caused by improper antenna control signals.
                    How to correct radio problem:
                    After invoking a rx(True) in your script, add the following two "radio pokes" to restore proper operation:
                    pokeRadio(0x000c, 0x12) # GPIO_1 CONFIGURATION REG - set to TX
                    pokeRadio(0x000d, 0x15) # GPIO_2 CONFIGURATION REG - set to RX
                    "
                    I am not entirely certain to which software the revision refers to but my portal is running at 2.4.17. Will look to try to confirm firmware on modules themselves. I hope this is the magic bullet I have been looking for!

                    Comment


                    • #11
                      Success with the RF300 at last!!!!


                      I had a couple RF300PD1 on my company's latest prototype boards with serial connectivity and no RF connectivity for some time now. Well, after all this time and a bruised forehead, I decided to go through every getInfo and getStat parameter possible with a fine tooth comb. I noticed the two nodes showed different vendor IDs, radio IDs, which led me to dig further revealing different firmware major, minor, build values (ver 2.4.9 on one vs ver 2.4.17 on the other) so I dug into the forum and found a posting with attached ver 2.4.17 and 2.4.20 firmware files. I loaded 2.4.20 onto both units and vuala! RF connectivity right away, as it should be! I had attempted numerous firmware upgrades and even thought that I had upgraded Portal to get the latest firmware for the units I apparently wasn't getting the latest version laoded onto the units. I have so many PCs that sometimes it's hard to keep track of which units run which version of Portal. I had assumed all this time that a simple "Upgrade Firmware" even after upgrading Portal would have given me the latest version possible. I'd like to make a friendly suggestion to Synapse, if it's not already out there (I can be a little blind sometimes), a page that is unmissable (No 72 font size on the hyperlink, that contains the latest firmware releases for MCUs and Engines running SNAP. Such a simple thing as the latest firmware shouldn't be hidden away in a relatively obscure forum posting. The important part is that my project can now move forward and maybe this post helps someone else who might be experiencing such difficulties.

                      Comment

                      X