|
Post by David MSGC on Apr 20, 2017 13:25:29 GMT -7
Actually it does not matter if the radios are swapped in order for it to work, it does matter if the occams boards are swapped. The microcontroller on the occams boards have different firmware. The xbees do have one radio as the coordinator and one as the end device. The end device uses a lot less power and this is why the documentation tells you to have it on the cutdown side, the cutdown is made as small and lightweight as possible and has a very low capacity battery. The radios are in transparent mode, which means they just repeat what they receive, the radios are just creating a serial connection between the two occams. If the xbees were in API mode it does matter what radio is where, but they are not in API mode. So if the radios are swapped it will still function, but you do want to PUT THE END DEVICE ON THE CUTDOWN SIDE as to not drain the battery. The iridium modem is not getting any feedback from occams so the change in queue is not related to the radios or where they are plugged in. The queue is updated when Iridium get the acknowledge from the modem not from occams. If the queue was at one, the original message was sent and cutdown should have ran. If the queue is at two, that means the previous message is still pending. Levi is right about the LEDs on the xbees, this is a good way to see if they are connected, the coordinator will always blink, the end device will only blink if it is connected to a coordinator, the coordinator will blink about 1 Hz and the end device will blink at about 2 hz. If both radios are blinking they are connected, the one that is blinking faster should be on the cutdown side.
|
|
|
Post by zerb196 on Jul 29, 2017 11:22:11 GMT -7
Hello all. Our team is also having trouble with the cutdown, and have attempted all the solutions in this thread. We know that the Occams and Xbees are arranged correctly because the E and C Xbees are on the End and Coordinator Occams, and the end Occams ASC light blinks at twice the frequency as the same light on the coordinator Occams. We have verified several times that our IMEI number (300234064801830) is correct. When we bench test, we ensure that all lights are green, the GPS is coming through on the BOREALIS site, and we follow the exact procedure outlined in the "Field Operation Overview" slide on the iridium assembly and operation PDF documentation. We send our commands for idle to data@sbd.iridium.com with the subject "300234064801830" and attach the sbd files with the password 12345678 as stated in the documentation. For idle we use pin combination {clear, clear, clear} and for cutdown we use {clear, clear, set}, as stated in the field checklist PDF. We have also tried {set, clear, clear} as described in this thread and also had no results. We have yet to observe the RSSI light flash when sending the commands, but the queue does clear down to 1 every time. We have also recharged the 6600mAh lipo on the iridium and tested that the cutdown lipo has enough charge to spin the motor.
The only real uncertainty is in the way we make the commands. Can someone verify for us that 12345678 is indeed the correct password, and whether the cutdown pin combination is {clear, clear, set} or {set, clear, clear}?
Thanks!
|
|
|
Post by kdvoigt on Jul 29, 2017 15:57:41 GMT -7
Zerb, we tried to do that, but the output pin states of CLEAR and SET on Remote Configure did not work for us. We downloaded a cutdown_100 file from Montana and an idle_000 file from Montana. I really wonder if we all have the incorrect version of Remote Configure. When we used the MT downloaded files to attach to the emails, we got the cutter to work (one day only). Today it's not working for us, and I have no idea what the problem is.
But you can try downloading their files. It's on the first page of this thread. It says something like, "you can get the files here" and that part of the text is a hyperlink. It takes you to a drive, and you can download the files.
Looks like we're working on the same problem at the same time! My email is kellye.voigt@palmettoscholarsacademy.org if you want to email me.
|
|
|
Post by kdvoigt on Jul 29, 2017 16:20:41 GMT -7
Zerb, we found our problem. One of our Xbees was put on the board backwards today. I do not understand how that happened because they have a trapezoidal configuration that shows you how to place on the board. But we have lots of younger students involved, and maybe one of them moved it today. My senior student figured it out. Once it was turned around the board, it immediately started responding.
Fingers crossed that your cutter starts working, too.
|
|
|
Post by zerb196 on Jul 31, 2017 6:30:47 GMT -7
Congratulations! We have been using the downloaded sbd files as well, and we know our xbees are on the correct way and are communicating with one another, so we fear it may be something wrong with the occams board on the cutdown side. We see the RSSI light come on when we send emails, so we know that data is being transferred too.
|
|