Communications Subsystem Design

by Michael Moore

This episode of technical corner will be regarding the design of our communications systems that satellite uses.

When looking to create a communications system for our CubeSat we first looked at the possibility of using the on board communications systems of our phone, the available communications were through the GSM networks (the networks used for standard mobile applications such as phone calls and text messages), the Wi-Fi connection and Bluetooth. Due to the lack of signal at these altitudes, the GSM network wasn’t a viable option. The Wi-Fi and Bluetooth frequencies were too high and would be attenuated by the atmosphere too much (this basically means that signals would diminish due to interaction with the atmosphere) so another solution was required, and we chose to create a communications modules from scratch.

The frequency that we chose to use for this application was 433Mhz, this is because it is legally compliant with UK regulations through OFCOM. 433Mhz is used as a standard ballooning frequency, giving us confidence that it would be able to transmit and receive at the desired altitudes. Creating a system from scratch meant that the layout of the system would be quite easy to change for use in an actual satellite as all that would change would be the frequency of the transceiver and the power of the system.

The objective was to create a small computer board that would take data from the main satellite computer (the smart phone) and transmit it at a desired frequency, whilst also being able to receive data and relay it to the smartphone. To do this a transceiver was used that operates at around 433Mhz.
The internal memory built into the transceivers which were within our price range were quite low, and this meant that we would have to add in a memory chip to the communications system. The memory chip was used so that if the transceiver memory became full before the data was dumped to the phones hard drive, the memory chip could pick up extra information to ensure that no data was lost because it had nowhere to be stored.
Unfortunately, getting the transceiver and the memory chip to interact in such a way requires the use of a microchip.
Knowing the 3 components that are needed for out communications board I started reading into the specifications of the transceiver, the microchip and the memory chip to work out how they should be connected together electronically. In the data sheets of these devices there are certain diagrams which give indications as to which pins coming off of the modules do what. above is an example of how the transceiver might connect to a microchip.


This had to be done with all 3 devices separately, and the images had to be collated and superimposed so that the memory chip, the transceiver, and the microchip would all work with one another. Once this had been done the below diagram was created.


There are a couple of extra modules which must be noted here, these include the voltage regulator which had to be included so that the input voltage of 5.0 from the USB could be transformed down to the 3.3v required for the microchip and transceiver to operate. Also, the USB hub is used to power the board and to allow the information to travel to and from the smart phone.


There are also a few extra capacitors and resistors that have to be added to the diagram, these are from reading the specifications of the modules in more detail. An example of one of these modifications is the capacitor between pin 10 of the microchip and the ground tracks. This is because pin 10 requires a voltage of 2.5 as opposed to all the other voltage pins which require 3.3. rather than using another voltage regulator just for this pin, I found that the microchip has an internal voltage regulator that can be used to power pin 10, and this is done by connecting pin 18 to the 3.3 volt supply, and then connecting pin 10 to ground via the capacitor, in the datasheet this is shown by the diagram above.
There are also capacitors added between the voltage and ground tracks, this is to ensure that any voltage peaks that occur when the device is activated do not travel to the chip and harm it, but instead are ‘cushioned’ by the capacitors. From pin 7 we can also see a configuration that must be used to enable the programming of microchip.

From this stage the above schematic had to be translated onto a model that could be sent off and produced. For this purpose the software DesignSpark was used, this is software that can be downloaded for free with a simple google search, and was recommended to me as it is often used by electronics students at Southampton University.
To the left you can see the layout of the board that will be used for printing purposes. There are a few notable points in the model; The ground tracks (wires) are connected to what is termed a ‘copper pour’ which are the large red areas of copper on the model, these are used instead of simple tracks to reduce the chance of electromagnetic induction which may cause problems with the electronic devices. It can also be seen that there are tracks of different widths, this is because some tracks are only carrying information signals, and hence they are very low voltage and current and do not have to be very large, however the power tracks are larger to avoid a loss of power through resistance. On the model the red and blue colours represent the 2 different sides of the board, and this shows that the tracks don’t cross one another as on the original circuit schematic, as this would short the circuitry.


The electronics have also been transferred onto a breadboard to ensure that they work as we want them to, and to enable the testing of the microchip programming. This is the stage we are now at and the board will be printed once the programming is shown to work.

I hope this gives an understandable, quick overview to the communications subsystem, please direct any further enquires to

Post a Comment

Your email is kept private. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>