I’m working on a 3U, and I’m also setting up a SatNOGS ground station. I’m wondering what data rates people are getting at their stations. I need a realistic number so I can see if we can push images across SatNOGS network successfully.
Does anyone have a bps average they can share? I’ve got about two thirds of a dual helix built, but I know I’d need more than just my station. I’m also wondering what a realistic data rate will be for my own station.
Thanks
We have successfully tested up to 9600baud on UHF and VHF (uplink and downlink on both).
What band is your cubesat COMMS on? Have you considered S-band? We are working on that too. Do you have a timeline?
The launch is December 2017. I am open to suggestions. I was going with 434 MHz, because it was in the ham freq range. I also have a helical tuned to 434.
We need to downlink for images. I’m concerned that the jpgs that they want to send will not be transmitted with the time(7-11 minutes)/power (1W) constraints. The cubesat comms that I’ve seen have such a bad S/N ratio that I’m not sure we can get anything useful.
I’m particularly concerned because the ground team and the flight team are working separately. I just got asked to review and fix the comms group. So I’m looking for a solution that I can move a jpeg of about 20KB down, and then pick the signal out of the noise.
I may be able to win a fight over power, but we will still be limited to what we can get on a 3U. We may have a cap bank, for burst transmission.
Some people are convinced that we can sew the image back together. I’m less convinced. If we program the sat to only transmit during a specific time and then send the packets in sequence, we could easily miss a packet. Since these images is our reason to fly, I really don’t want to miss it.
Do you have recommendations?
We are a secondary payload, so we don’t have much control of the orbit. The orbit is subject to change.
Hello,
First of all, JPEG might not be the best format for the transfer. We have selected PNG for UPSat. The difference is that if you lose a packet in JPEG, you can lose the whole image, while with PNG you only lose a line of the image. Also, PNG is lossless so you will eventually get the original image.
Indeed, it is difficult if not impossible to receive the whole image in one pass. What you can do is acquire the image, split it into tiles and store them individually on the satellite. Depending on the size of the image, you can then command the satellite to send a set of them during a pass. If a tile is corrupted, then you can command it to send it again on the next pass.
… and those are all for 9600 baud on UHF. Obviously going up to S-band tremendously changes this scenario. Are you flexible on doing that @nweideman1?
We came to the same conclusion to use png, but there is no intent to have command function, just transmit. I have to code the comms system prior to launch, without the ability to make adjustments in orbit. This is a decision of the PI.
I’ve strongly advocated S-band and have been overruled by the PI repeatedly. I’m going to do one more presentation, but he is convinced that with a 0.5 watt of power to the TX, an uncertain orbit, at 434 MHz, a tape measure antenna, no command function, and SatNOGS, we can Tx/Rx a 20KB (color) image a day.
I’m attempting to build a case for a better antenna, or S-Band, or a more robust ground solution. In pursuit of this, I’m trying to quantify the power loss and the noise.
Other cubesats have used tape measure antennas, but I haven’t found one that was transmitting images on a receiver like SatNOGS. So I’m wondering what the real world experience form the community has been, because I find myself less than confident.
I’d like to replace the tape measure omni antenna with a directional, but we are going to flip every time the SC orbits. The PI and his manager, are not willing to change their design. They are also convinced that the stabilization will never complete before it has to flip again.
So I have to waste what little power I have on the rest of the Universe, use a noisy antenna, Tx an image, and keep the cost of the total comms package down to less than a grand.
So, I’m doing one last attempt at trying to show numerically how that may not be a good solution.
I see… How about adding FEC? It would increase the size of the transfer but if you store the image and retransmit it multiple times then it could be possible to recreate the image by combining the data from multiple observations.