Author Topic: sub-GHz Transceiver PCB layout and Design, Where do I Begin Learning all this?  (Read 1183 times)

0 Members and 1 Guest are viewing this topic.

Offline jaregomontenego

  • Newbie
  • Posts: 2
  • Country: ph
Good Day!

I'm not sure what level of competence I have with regards to the topics I discuss, but I still consider myself a "noob" in regards to whatever is down below. And so I try my luck in the beginner section.

I am involved in a project that calls for the use of VHF Communications in the sub-GHz band (in the Marine Band). The data transmitted is digital in nature, modulated/demodulated by using GMSK. The technology is called Automatic Identification System (AIS), and is an already existing technology, widely used on ships to aid in ship vessel tracking and collision avoidance. Antennas used are omnidirectional, therefore data is always broadcasted. Before we design a transceiver for the project, I want to gain more knowledge on the following topics:

-VHF Antenna design/theory
-VHF Transmission lines, Impedance matching, cable termination
-Discrete component RF filter designs and considerations
-PCB Layout of RF components, filters, amplifiers
-PCB Layout considerations when using RF transceivers on the board
-GMSK and clock recovery
-Radio Propagation at sea (including considerations in K-factors, earth curvature, refraction, reflection,  fade margin, power budget, etc.)
-RF frequency and power measurements

I already have a basic knowledge of RF, in which I have a broad understanding, but not in an industrial nor practical depth.

I want to find online courses, guidelines, or any supporting material that would help shed some light in what I need to consider with the project design. I need someone to point me in the right direction.

As to why I posted here, this is the bulk of the reason:

I know next to nothing in practical RF systems. We just used a telescopic center-fed 1/2 wavelength vertical dipole, and based on the frequency, 162MHz, we adjusted the end-to-end length of the dipole to 0.923 meters (lambda = 3x10^8 / 162x10^6 = 1.85 meters ; lambda/2 = 1.85/2 = 0.923 meters). Is this right? Everything we have performed is all based on theory we have learned during our undergraduate degree. Even if it is, is the 1/2 wavelength dipole the best solution? I see whip antennas where the coax cable was connected to one end, and I have no idea how that works, because what I know is that a lambda/4 antenna needs a grounding plate, but there isn't any grounding plate on this vertical whip. How is it that an end-fed antenna works the way it should? does the end effect have to be considered here? Are there more antenna considerations I have to consider? Am I overthinking?

How about impedance matching? Assuming we got the antenna right, we just used a thin SMA coaxial cable. Do we really need to consider, down to the millimeter or to any appropriate scale, the length of this cable when doing impedance matching? How about the terminations, capacitance, inductance, the bandpass filters to use, as well as amplifiers? Individually, I have the means to research and understand these topics, but to meld all these considerations and ideas together into one OPTIMALLY WORKING system, How am I supposed to tackle this?

Then it goes down to the PCB on the transceiver (I have no PCB design experience, only doing simple circuits using PCB Wizard to design the circuit, using a pre-sensitized PCB, using UV light to embed the acetate circuit pattern on the board, then manually etch with ferric chloride). Since RF signals will have to pass down from the antenna and the coax cable (assuming I have done the proper optimizations for these, which I haven't), how do I proceed in terminating the cable? Aside from impedance matching, I have no idea as to how parasitic capacitance/inductance comes into play, and if and how the traces on the PCB is supposed to be optimally laid out for specific frequencies, how the PCBs are supposed to have these holes called "vias" for RF applications and how it helps in whatever way it does help? Am i missing on things to consider in PCB design? How do I go about designing the filters for this frequency?

Am I overthinking? Are these things supposed to be tackled as each problem occurs? :-// :-// :-//

I absolutely have no clue of how to tackle all this, and I think that a review of my RF fundamentals is a must, but I'm not sure where to start anymore. Any material you know of, or advice for proceeding with this would be truly helpful.


You can stop reading at this point, but if you want to get a grasp of what the end goal of what we are doing should look like, I encourage you to continue reading.
As for the things the team has already done in relation to the project:

1.  SDR Receiver Implementation

We have created a working AIS Receiver using a Software Defined Radio (SDR), namely the HackRFOne. Before we make a transceiver with a discrete-component design, we made sure that we understood the theory, and apply what we have learned from reading all the standards related to AIS, and so we used a Software Defined Radio to define what should have been hardware blocks like filters, GMSK demodulators, all through software instead.

As to how it is performed, I just know that as an SDR captures the data, it is not recorded/processed as the values of the electromagnetic fluctuations observed in a particular frequency (a "real" signal), but as a quadrature signal (I and Q), and due to the additional properties we can observe from quadrature signals as compared to just plainly processing its "real" RF signal counterpart, all these filters, modulators, dc offset, etc., leverage particular cues or thresholds in these additional properties, and can all be defined through data manipulation with the help of Digital Signal Processing.

All ships equipped with AIS devices transmit their information in the 161.975 MHz or 162.025 MHz channels (each channel uses 25 kHz bandwidth), with a baud of 9600. The SDR samples the RF signals. The data is then processed by the block diagram generated through GNU Radio. We end up with the original digital data, and is passed to a Python script I made for processing the data.

One AIS message begins with a 24-bit training sequence (a sequence of alternating 1's and 0's, followed by an 8 bit start flag (0111 1110, or 0x7E in hex), followed by a bit-stuffed data (bit-stuffed means, at least for the AIS standard, that for every five consecutive '0's, a '1' is appended, so if I were a receiver of this message, everytime I see a sequence of '100000', I ignore the appended '1' as it is not part of the original data.), and then a 16-bit CRC of the non-bit-stuffed data. the message ends with an 8-bit end flag(0111 1110, or 0x7E in hex, same as the start flag).

Going back to the Python script, I confirm that data is a legitimate AIS message when the length of the data is exactly 168 bits (at least only for a particular message type), and if the CRC checks out. The data is then processed into fixed-length fields, where each field defines the particular information the ship's AIS was originally transmitting (GPS coordinates, MMSI, call sign, IMO number, COG, SOG, etc.)

AIS messages are transmitted over only two channels, and these two channels are shared by all ship vessels in a vicinity. How does AIS make sure that no message collisions/interference occur? AIS uses Time-division Multiple Access, sort of like a schedule where all participating AIS devices agree upon. A particular AIS station on a ship, will autonomously determine when it transmits, in consideration to the current state of the transmissions currently occurring on the two channels, and will automatically avoid transmitting at times when it knows that another AIS station has "reserved" that particular time in advance, through a different AIS message type. How do all AIS devices synchronize their "time"? Well, all transmitting AIS devices must have a GPS device, and through the UTC time obtained from the GPS, all vessels know that they are synchronized to each other through the UTC time.

The AIS standard defines that for every channel, there are exactly 2250 slots an AIS can choose to transmit to, of course considering data collision. Each slot is assigned a slot number, numbered from zero(0) to 2249. If an AIS device were to transmit on slot zero(0), the moment the AIS BEGINS TO TRANSMIT on slot 0 is exactly aligned to the beginning of a UTC minute. If an AIS device were to transmit on slot 2249, the moment the AIS ENDS ITS TRANSMISSION on slot 2249 is exactly aligned to the end of a UTC minute. So, if 2250 slots are allotted for one minute, the time it takes for an AIS to complete its transmission of one (1-slot long) message is 26.667 milliseconds. 

Now then, we go back to the SDR. The python script is designed to look for the training sequence, start, and stop flag, which is totally independent from the UTC-based slot definition. I fear that the UTC-based slot reception, continuously checking every 26.67 ms for a slot number transition and checking the contents of the data at that slot, is too computationally involved, and synchronously unreliable, since the SDR is still dependent on an external computer to run GNU Radio, and especially because initially, the plan was to control the SDR with a Raspberry-Pi (we use a normal desktop PC for the moment) and I'm not sure if the current setup can handle all the responsibilities of synchronization, transmission, reception, etc at such a time-critical application. The HackRFOne can be programmed to work in a stand-alone mode, since it has an ARM microprocessor, but in terms of embedded programming, I know next to nothing  :-//. This is all in consideration to the fact that the TDMA algorithm has not yet been included in the tasks involved in AIS reception (We are currently working on the algorithm for this, and is much more computationally involved as compared to the code just for the reception of the data). We decided that we need a more dedicated solution compared to a PC or a Raspberry Pi, and so we decided to go and study how to use microcontrollers, and buy a programmable radio to be controlled by the microcontroller.

2.  Microcontroller and Programmable Radio

We found a project called dAISy, which is a microcontroller based project for AIS reception in this forum :
and decided to try out building one from scratch as a practice for the embedded implementation for the project. Initially, he used an MSP430G2253 Launchpad board (which I currently have and currently studying its use) and this microcontroller talks to a programmable radio (Silicon Labs ezRadio Si4362) through SPI. But since we plan on creating a transceiver, we bought an Si4463 transceiver radio instead (he mentioned in the forum that the systems are compatible to each other).

And so this is the current state of the project. Were waiting for the materials to arrive, and so for the meantime, I tried to research ahead of what things we have to consider, which brought me to posting this long rant. The main gripes I have considered has already been stated above as the bulk of my current problems. I just feel like I'm lost in a sea of information

I thank you in advance for any help,


Offline iainwhite

  • Supporter
  • ****
  • Posts: 303
  • Country: us
  • Measure twice...
Possibly read:
High Speed Digital Design: A Handbook of Black Magic by Howard Johnson and Martin Graham  ? ?

I have not read it myself but the title crops up in other threads on similar subjects.  Maybe other members can advise.
The following users thanked this post: jaregomontenego

Offline rhb

  • Super Contributor
  • ***
  • Posts: 2730
  • Country: us
Both the books by Johnson and Graham are excellent and should be on your bookshelf.  However, there is a *lot* more to RF design than what they cover.  They are really about brutally fast digital logic.

Of the books I have, "RF Circuit Design: Theory and Applications" by Ludwig & Bretchko  would be my first recommendation, even before the "black magic" books.  RF layout resembles witchcraft until you understand it.  I'm also trying to learn the same things, but just as a hobby.

Another recommendation is "Antennas" by Krauss.

I'd also suggest the ham radio literature covering VHF as 144 MHz is a very popular band

At the moment I don't have a good modern RF reference that covers SDRs.  I've been looking for the sort of stuff you're seeking for some time, but not found anything.  So I shall be interested to see what others suggest.  I have a LimeSDR, but have not got it packaged and going. 

For a commercial project I think you'd be better off getting a B2XX from Ettus Research.  I've not done anything with one, but they seem to be the mainstay of most of the professional level work I've seen and appear to have better software support.  Part of the reason I've been slow to tackle the LimeSDR is lack of confidence that the software is stable.

There are a number of radio propagation modeling codes available.  I can't say much about them, but some of them have been around for quite a while and have very credible pedigrees.  There's been a lot of work on propagation in recent years, but most of it is devoted to cell phones.
The following users thanked this post: iainwhite, jaregomontenego

Offline awallin

  • Frequent Contributor
  • **
  • Posts: 622
The following users thanked this post: rhb, jaregomontenego

Offline rhb

  • Super Contributor
  • ***
  • Posts: 2730
  • Country: us
AD has an SDR book out quite recently:

After a look at that book, I think it's an excellent place to start, especially if you don't have a *lot* of DSP experience.  Even better is AD offers an SDR Xcvr used in the book for exercises.

While AD list it at $150 on their website, it's available from Mouser and Digikey for $100.  It's practically a full implementation of your product.  It just needs  amplifiers,  bandpass filters and mixers to convert the signal to and from 162 MHz  from an IF above 325 MHz.  It would probably make an excellent basis for your product, but AD has RF front ends with more dynamic range if you need it.  My guess is that 12 bits is sufficient once you add amplifiers and bandpass filters.

In any event, you can immediately start developing your firmware with $200 in hardware independently of the RF front end and PA stage development work.  Buy connectorized amplifiers, mixers and LOs from MiniCircuits and you can have a working prototype in a few days probably  for under $1000 US.  That will give you lots of time to perfect the FW while you study the PCB design issues.

The Zynq 7010 has serious DSP performance and a pair of ARM cores with NEON FPUs.  It forms the guts of the GDS-2000E line of DSOs from Instek and the corresponding line from Siglent.  All the other SDR options I know of require a connection to a computer.

I plan to get at least one and probably two for myself.  I have no affiliation with AD or Xilinx.  But the combination of the book and the eval kit is *very* compelling.  And you can be confident that AD will support you.  They want to be in your design.
The following users thanked this post: jaregomontenego

Offline jaregomontenego

  • Newbie
  • Posts: 2
  • Country: ph
Thanks to all of your insights regarding this topic! Ill surely look into each of your approaches.

For the time being, I found a talk conducted by Michael Ossman (he created the HackRFOne, link here, and he had similar problems with what to think about when creating an RF PCB layout, and he decided not to perform a "traditional" approach, and instead found a simpler procedure, which are just to follow five rules when making RF PCB Layouts:
1. Use 4 Layer PCBs
2. Use Integrated Components
3. 50 ohms everywhere
4. Follow Manufacturer's Recommendations
5. Route RF first

These were also the same rules he used in making his various products. Of course, I want to be able to understand more of the theories related to traditional PCB design, and have the assurance that every aspect of a design I make is backed up by some proper principle or theory. But at the moment, I would just want to try out his approach for RF design. His talk really shed some light into some of the dillemas he faced that where similar to my own problems.

Regardless of whatever route I take for the project, Im still properly going to look into the reference materials you guys have mentioned, and perhaps maybe I could perform separate prototypes using the simple approach on one and the traditional approach on the other, and share the differences between them

But what do you think about this material I found? I'd love to hear more of your insights

With gratitude,

Offline rhb

  • Super Contributor
  • ***
  • Posts: 2730
  • Country: us
The 5 rules seem pretty traditional to me.  Good luck.

Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo