CX Edustation Team Members: Please login and answer the questions directly on this webpage (i.e. hit the EDIT button below).
Mark, can you answer the following questions and fill in the table:
- how do you want to perform the encoding/unencoding? Would you like to perform it on every packet or would you like to reassemble the packets into a file and unencode the whole file? My first inclination would be to encode each packet because then we'll have at least partial information even if packets are lost.
- about how much overhead will we have to add per packet to still be able to repair X number of bit errors per 255 byte packet? We would like a table indicating something like:
| Bits fixed | Additional bits needed
|
| 8 per packet | 4% = 10 bits
|
| 16 per packet | 10% = 25 bits
|
| 32 per packet, etc | 20% = 50 bits |
From Matt's email and talking with Dave, this is what needs to be happening over the next two weeks (with tenative due dates):
- Dave Brown installing existing Edustation software on his computer and testing that it works (i.e. it comes up) and learning what exactly it does! This may require looking at EdustationJava? code from CVS. The CX Project Leaders may be asking for a demo of the existing software sometime soon so let me know what you can do with it. Due date: 3/15/04
- Blair trying to get specifications on the response of the VFO on the ICOM radio. How long does it take to switch frequencies and if it loses the frequency lock, how long does it take to switch freq and reacquire? Due date: 3/10/04
- Blair to see how much offset the ICOM can deviate from its carrier freq before the BER becomes too great (see *** below for more details) Due date: 3/15/04
- It sounds like Zach is willing to meet Matt at about 8:00pm on Wednesday (after this meeting) to do some testing. Matt would like Dave (and probably Blair) there if you can to help. Dave and Blair, email Matt back to let him know if you will be there. I don't know what your test plan looks like, but I guess I would suggest:
- hooking up ICOM and antenna to a computer (does not necessarily have to be the one it is attached to currently if that one won't work for you. Need a laptop?)
- monitoring the serial port with Hyperterm or Kermit
- using a second radio to broadcast something. This second radio (you would be the best judge) could be a handheld, the CXGround in the MOCC, or even the 3CS satellite sitting on the desk in the Design Area. (If you want to use the threecs SisterSat?, I have a few quick cmds that you can easily run to broadcast something. Let me know.)
- First step is to get some characters to appear on the Hyperterm
- Second step is to see if you can cause the ICOM to switch frequencies and see if your second radio still sends characters to the serial port of the Edustation.
- Third step, see if you can time how long it takes to switch freq and see if characters stop coming in while you are in "switching" mode.
- Test that you can receive characters using different antenna designs.
- If you can receive them, then how do we tell which one is better? Drive the transmitting antenna a few miles away?
- Depending on the outcome of the above test, we need to give Dave Brown a definitive answer on if we need code to change the ICOM's frequency from the Edustation software. Due date: 3/17/04
- If we cannot accept the performance of the ICOM, is there another cheap radio that will work? Is there an "out-of-the-box" solution anyone can think of? Due date: 3/17/04
- If we can't think of one, should we try the "software radio" method? Let's draw out the block diagram of how this will work before Spring Break if we need to. I would like to send this onto some Ball experts to see if they think it's plausible. Due date: 3/19/04
- What BER do we expect? This number will probably feed directly to Mark to determine how much overhead we need to add, then ultimately, how many packets per H&S we need. I think the current telemetry packet is 407 bytes long, so right now, without encoding, it takes at least 2 packets of 255 bytes each (assuming that AX-25 doesn't add more than 50 bytes per packet). Due date: 3/15/04
(***I also did a quick Google search on `"how much" doppler shift amsat` and got the following link:
http://www.amsat.org/amsat/archive/sarex/200105/msg00196.html (cache)
This link says that "+/- 3.5 Khz is the max" for ISS. Can the ICOM take this shift without the freq being reset? (if so, should we stop worrying about changing freq) Depending on the offset it can take, lets divide this by about 10 minutes per pass to determine how many times we need to switch frequencies. Once we get this number, how many seconds (or packets) do we expect to loose?
