I don't think the files are made to be opened. The utility that creates them takes the settings you want and creates a tiny, machine-readable file for the satellite company. Those tiny files are the ones we keep on our google drive.
If you're stuck on the official docs, check out our team's troubleshooting doc. It has a section on sending the files, creating them, and using/resetting the built-in cutdown timer. All the cutdown things we've learned so far.
You are right, they are not meant to open. But, if I understand this correctly that one file attachment serves for purpose to stop the motor from spinning and also to get it to spin. I do have a question, as we are going over the checklist, the "Remote Configure" sreenshot window shows (p. 25) the pins 0, 1, 2 in terms of "True or False" on our laptop these show as "set or clear" for each of the digits. Does this makes a difference? The reason I ask is because the cut-down motor is not moving at all. Sent email today to firstname.lastname@example.org with the sbd file from last July attached and IMEI number on subject line and nothing happened, just this reply "Attachment Filename: Idle_...make spin motor.sbd Attachment Size: 15 The MTMSN is 20, and the message is number 1 in the queue."
If you're making a new file, yes, the pin states do matter. It's been awhile since I created a new file because I just keep reusing the files I made during the workshop. However, I do kinda recall them saying there was a typo and the correct pins were slightly different from what we were originally told. I don't know if the pdf you're looking at has the correct values or not.
You might try using my cutdown file and if it works, keep using it. Or maybe someone with more intimate knowledge of the correct cutdown pin pattern can chime in and set the record straight.
I was curious so I checked. The remote configure tool has a box for the IMEI number but it looks like it's only used if you use the tool to send the SBD file. If you're using email, the files should be interchangeable.
I could be wrong as I don't have a second unit to test this with, but.. that's my theory. Our IMEI number was not used to create our files.
It DOES ask for a password, but I believe we're all using the same super secret password.
We're trying to send the cutdown command using Iridium but it's not working out. We're using the cutdown_100.sbd file found in the drive. The Iridium light, GPS light, and Status light are all solid green and the email reply says The MTMSN is 2, and the message is number 1 in the queue. Do you have any suggestions of where to go from here?
Every time you send the payload a command it increments the MTMSN, so it just continually counts up. The queue empties as the messages are delivered to the payload, so that number can be used to help debug what's going on. If the queue isn't going down then the payload isn't connecting to the satellites. (As far as I know.)
A few things that MIGHT be going wrong:
1) The two xbee radios on the small cutdown, and big irridium tracker portions look identical, but one is actually a sender and the other is a receiver. So if you swap them by accident during assembly, the payload won't cut down. I don't know of a way to check if they are swapped because they look identical, I think the only difference is the software installed on them.
2) You may have used the wrong IMEI number in your email, double check that it matches the number on the bottom of the irridium satellite box with the lights.
3) Try sending another cutdown email and see if the queue number goes up, or remains at 1. This would tell you if the message is getting through or not.
4) Verify that you can hit the 'motor' button to spin the motor on the cutdown side (watch your fingers). This seems unlikely but would point to a hardware or wiring problem.
If all else fails, try taking some close up pictures of the various components and maybe someone will spot something. Good luck!
After sending more commands the MTMSN is counting up as you said it would and the queue remains at 1. After switching the xbee's, the queue went to up 2, which means the original setup was right. We've been using the cutdown procedure in the slides, including resetting the OCCAMS. Attached are some close up shots of the Iridium and the cutdown payloads.
Last Edit: Apr 19, 2017 18:08:51 GMT -7 by marcellus
Before we move on from the possibility of the xbees being swapped, let's check the lights. I remembered seeing something useful in the OCCAMS documentation that says:
There are two LEDs that show the XBee connection status. The ASC light shows the connection status as a function of flash rate while the RSSI light shows data traffic both receiving and sending. These lights are labeled with the white silkscreen on the OCCAMS boards on the back. The ASC light will flash faster when connected to another modem wirelessly. End Devices flash very fast when connected (~4 Hz) where coordinators speed up from about 0.1Hz to 1Hz.
If I'm understanding this correctly, one xbee is a 'end device' and the other is a 'coordinator device.'
Essentially, you want to make sure the ASC light on the xbee with the cutting motor blinks faster than the xbee with your irridium box.