An Open Source Tool For Researchers and Developers

Carles  Fernández-­‐Prades,  Javier  Arribas,  Pau  Closas,  Carlos  Avilés,  Luis  Esteve  Centre  Tecnològic  de  Telecomunicacions  de  Catalunya  (CTTC)  

Outline  

•  MoEvaEon  •  Philosophy  •  SoIware  Architecture  •  Development  Ecosystem  •  Conclusions  

Motivation

•  LocaEon  has  become  an  embedded  feature  in  electronic  devices  (phones,  digital  cameras,  portable  gaming  consoles).  

•   This  massive  deployment  of  GNSS  receivers  requires  a  high  level  of  integraEon,  low  cost,  small  size  and  low  power  consumpEon.  GPS  integrated  circuit  (IC)  manufacturers  offer  single-­‐chip  solu5ons  easy  to  integrate  in  mulE-­‐funcEon  devices.    

•  This  approach  is  very  convenient  for  locaEon  based  services  and  applicaEons,  since  users  and  developers  are  interested  in  using  the  locaEon  informaEon  but  not  in  how  the  posiEon  has  been  obtained.    

•  Example:  Android’s  API.  It  provides  a  locaEon  package  that  contains  classes  with  methods  such  as  getLaEtude(),  getLongitude(),  getAlEtude(),  getSpeed(),  getAccuracy()  and  so  on.  

•  LocaEon  has  become  an  embedded  feature  in  electronic  devices  (phones,  digital  cameras,  portable  gaming  consoles).  

•   This  massive  deployment  of  GNSS  receivers  requires  a  high  level  of  integraEon,  low  cost,  small  size  and  low  power  consumpEon.  GPS  integrated  circuit  (IC)  manufacturers  offer  single-­‐chip  solu5ons  easy  to  integrate  in  mulE-­‐funcEon  devices.    

•  This  approach  is  very  convenient  for  locaEon  based  services  and  applicaEons,  since  users  and  developers  are  interested  in  using  the  locaEon  informaEon  but  not  in  how  the  posiEon  has  been  obtained.    

•  Example:  Android’s  API.  It  provides  a  locaEon  package  that  contains  classes  with  methods  such  as  getLaEtude(),  getLongitude(),  getAlEtude(),  getSpeed(),  getAccuracy()  and  so  on.  

•  LocaEon  has  become  an  embedded  feature  in  electronic  devices  (phones,  digital  cameras,  portable  gaming  consoles).  

•   This  massive  deployment  of  GNSS  receivers  requires  a  high  level  of  integraEon,  low  cost,  small  size  and  low  power  consumpEon.  GPS  integrated  circuit  (IC)  manufacturers  offer  single-­‐chip  solu5ons  easy  to  integrate  in  mulE-­‐funcEon  devices.    

•  This  approach  is  very  convenient  for  locaEon  based  services  and  applicaEons,  since  users  and  developers  are  interested  in  using  the  locaEon  informaEon  but  not  in  how  the  posiEon  has  been  obtained.    

•  Example:  Android’s  API.  It  provides  a  locaEon  package  that  contains  classes  with  methods  such  as  getLaEtude(),  getLongitude(),  getAlEtude(),  getSpeed(),  getAccuracy()  and  so  on.  

What if you want to test

your own algorithm?

Wish  list  for  a  GNSS  soIware  receiver  

Philosophy

Design  principles  

•  Do  not  reinvent  the  wheel.  •  Follow  design  paXerns.  •  Follow  a  clean  coding  style.  •  Follow  standards.  •  Try  to  produce  a  well-­‐wri-en  soIware.  •  Test-­‐driven  development  approach.    

Design  paXerns  •  SoIware  design  paXerns  are  descrip5ons  of  solu5ons  to  common  so6ware  problems  arising  in  different  contexts,  capturing  recurring  structures  and  dynamics  among  soIware  parEcipants  to  facilitate  reuse  of  successful,  thoughYully  proven  designs.    

•  They  generally  codify  expert  knowledge  of  design  strategies,  constraints  and  best  pracEces.  Following  a  paXern  helps  to  resolve  key  design  forces  such  as  flexibility,  extensibility,  dependability,  predictability,  scalability,  and  efficiency.    

•  They  are  not  code  recipes  but  generalized  solu5ons  to  commonly  occurring  problems  

Test-­‐driven  development  

TesEng  

Coding  style  •  Following  programming  guidelines  and  code  convenEons  

not  only  helps  to  avoid  introducing  errors,  but  cuts  maintenance  costs  and  favors  effecEve  code  reuse.    

•  The  following  rules  capture  the  most  important  aspects  of  coding  style:    – All  should  be  as  understandable  as  possible.    – All  should  be  as  readable  as  possible,  except  when  it  would  conflict  with  the  previous  rule.    

– All  should  be  as  simple  as  possible,  except  when  it  would  conflict  with  the  previous  rules.    

•  Any  violaEon  to  the  guide  is  allowed  if  it  enhances  readability.    

Introducing  GNSS-­‐SDR  

•  The  acronym  stands  for  ‘Global  Naviga5on  Satellite  System  –So6ware  Defined  Receiver’.  

•  It  is  a  tool  for  researchers,  specially  focused  in  signal  processing.  

•  Flexible,  fully  configurable,  easily  extendible.  •  Testbed  for  GNSS  synchronizaEon  algorithms.  •  Programmed  in  C++.  Portable  (currently  builds  in  Linux  and  

MacOS  operaEng  systems.  The  execuEon  in  embedded  processors  in  FPGA  devices  or  ARM  processors  is  foreseen.)  

•  Open  Source:  free  as  in  free  beer  and  as  in  free  speech.  Released  under  GPLv3.  

Software architecture

Signal  Processing  in  SoIware  Radio  •  GNU  Radio  is  a  free  soIware  toolkit  for  building  soIware  

radios.                                    hXp://gnuradio.org/redmine/wiki/gnuradio        •  The  programmer  builds  a  radio  by  creaEng  a  graph  where  the  

nodes  are  signal  processing  blocks  and  the  lines  represent  the  data  flow  between  them.    

•  Conceptually,  blocks  process  infinite  streams  of  data  flowing  from  their  input  ports  to  their  output  ports.  

•  The  signal  processing  blocks  are  implemented  in  C++.    

gr_basic_block  

std::string  name()  gr_io_signature_sptr  input_signature()  gr_io_signature_sptr  output_signature()  

gr_hier_block2  

connect(gr_basic_block_sptr  block)  disconnect(gr_basic_block_sptr  block)  virtual  lock()  virtual  unlock()  

gr_top_block  

run()  start()  stop()  wait()  virtual  lock()  virtual  unlock()  dump()  

gr_block  

virtual  general_work()    

The  C++  class  gr_block  is  the  base  of  all  signal  processing  blocks  in  GNU  Radio.  

general_work()  does  the  actual  signal  processing  

Your  signal  processing  blocks  here  

general_work()  …  Your  flowgraph  

here  

…  

GNSSBlockInterface  

Acquisi5onInterface  

TrackingInterface   ChannelInterface   TelemetryDecoderInterface  

ObservablesInterface  

AcqA  adapter  

AcqB  adapter  

AcqC  adapter  

Trk1  adapter  

Trk2  adapter  

Trk3  adapter  

Trk3  GNURadio  

block  

gr_block  

GNSSBlockInterface  

Acquisi5onInterface  

AcqC  GNURadio  

block  

GNSSBlockFactory  

AcqA  adapter  

AcqB  adapter  

AcqC  adapter  

Strategy  

Concrete  Strategy  

Concrete  Strategy  

Concrete  Strategy  

Different  implementaEons,  same  interface  

Strategy  PaXern  

Client  

Reuse  of  exisEng  GNURadio  blocks  GNSSBlockInterface  

Acquisi5onInterface  

AcqC  GNURadio  

block  

GNSSBlockFactory  

AcqA  adapter  

AcqB  adapter  

AcqC  adapter  

Client  

Adapter  

Adaptee  

Target  Adapter  PaXern  

                                                       AcquisiEon  

GNSSBlockInterface  virtual  …  

gr_top_block  

…  

Acquisi5onInterface  virtual  …  

AcqA  adapter  

AcqA  GNURadio  

block  

gr_block  

AcqB  adapter  

AcqB  GNURadio  

block  

Top-­‐level  hierarchical  block  represenEng  a  flowgraph.  It  defines  GNURadio  runEme  funcEons  used  during  the  execuEon  of  the  program:  run(),  start(),  stop(),  wait(),  etc.  

                                                       AcquisiEon  

GNSSBlockInterface  virtual  …  

gr_top_block  

…  

Acquisi5onInterface  virtual  …  

AcqA  adapter  

AcqA  GNURadio  

block  

gr_block  

AcqB  adapter  

AcqB  GNURadio  

block  

Common  interface  for  all  the  GNSS-­‐SDR  modules  

                                                       AcquisiEon  

GNSSBlockInterface  virtual  …  

gr_top_block  

…  

Acquisi5onInterface  virtual  …  

AcqA  adapter  

AcqA  GNURadio  

block  

gr_block  

AcqB  adapter  

AcqB  GNURadio  

block  

Common  interface  for  all  the  AcquisiEon  implementaEons  

                                                       AcquisiEon  

GNSSBlockInterface  virtual  …  

gr_top_block  

…  

Acquisi5onInterface  virtual  …  

AcqA  adapter  

AcqA  GNURadio  

block  

gr_block  

AcqB  adapter  

AcqB  GNURadio  

block  

This  is  the  abstract  base  class  for  all  the  processing  blocks.  A  signal  processing  flow  is  constructed  by  creaEng  a  tree  of  hierarchical  blocks,  which  at  any  level  may  also  contain  terminal  nodes  that  actually  implement  signal  processing  funcEons.  This  is  the  base  class  for  all  such  nodes.    

                                                       AcquisiEon  

GNSSBlockInterface  virtual  …  

gr_top_block  

…  

Acquisi5onInterface  virtual  …  

AcqA  adapter  

AcqA  GNURadio  

block  

gr_block  

AcqB  adapter  

AcqB  GNURadio  

block  

These  are  different  implementaEons  of  acquisiEon.  Actual  signal  processing  is  done  here.  You  can  use  exisEng  GNURadio  blocks  or  implement  a  new  one  by  yourself.  

                                                       AcquisiEon  

GNSSBlockInterface  virtual  …  

gr_top_block  

…  

Acquisi5onInterface  virtual  …  

AcqA  adapter  

AcqA  GNURadio  

block  

gr_block  

AcqB  adapter  

AcqB  GNURadio  

block  

These  classes  adapt  your  custom  acquisiEon  block  to  the  common  interface  expected  by  AcquisiEonInterface  

Development ecosystem

www.gnss-­‐sdr.org  

•  Infrastructure  for  project  management,  code  development  and  efficient  communicaEon  among  users  and  developers  is  a  key  aspect  in  soIware  projects.  

•  The  website  should  be  well  designed  in  terms  of  usability,  funcEonality  and  extendability,  ensuring  an  enjoyable  and  appealing  user  experience.  

•  For  the  source  code,  we  used  the  service  provided  by  SourceForge,  which  allows  access  to  the  code  using  two  major  revision  control  systems  such  as  Subversion  and  git.  

•   Documenta5on  is  of  paramount  importance  for  users,  developers,  testers,  soIware  architects  and  students.  We  used  Doxygen  (HTML,  LATEX,  RTF  or  XML  output  formats).  

•  The  project  web  page  provides  with  detailed  instrucEons  about  the  installaEon,  usage,  coding  style  and  general  informaEon  about  the  program.  

•  The  build  process  should  be  easily  maintained  and  highly  portable.  We  used  Boost.Build,  a  tool  that  takes  care  about  compiling  the  sources  with  the  right  opEons.  Regarding  the  compiler,  we  used  the  GNU  Compiler  CollecEon  (gcc).  

•   We  suggest  a  test–driven  development  approach.  This  methodology  facilitates  change,  simplifies  integraEon,  automaEzes  documentaEon,  helps  to  separate  the  interface  from  the  implementa5on,  increases  developers  producEvity,  and  plays  a  central  role  in  the  soIware  quality  assurance  process.  For  unit  tesEng,  we  found  the  Google  C++  Tes5ng  Framework  (gtest)    useful  and  lightweight.    

•  Logging  is  important  for  debugging  and  tracing  purposes.  In  GNSS-­‐SDR,  logging  is  handled  by  Google  Logging  Library  (google-­‐glog),  a  library  that  implements  applicaEon-­‐level  logging.    

Conclusions

•  The  proposed  soIware  receiver  targets  mul5-­‐constella5on  /  mul5-­‐frequency  architectures.  

•  Goals:  efficiency,  modularity,  interoperability  and  flexibility  demanded  by  user  domains  that  require  non-­‐standard  features.    

•  The  source  code  was  released  under  the  GNU  General  Public  License  (GPL),  thus  ensuring  the  freedom  of  modifying,  sharing,  and  using  the  code  for  any  purpose.    

•  This  secures  pracEcal  usability,  inspecEon,  and  conEnuous  improvement  by  the  research  community,  allowing  the  discussion  based  on  tangible  code  and  the  analysis  of  results  obtained  with  real  signals.  

•  It  is  also  intended  to  be  a  framework  for  algorithm  tesEng  and  an  educa5onal  tool.  

gnss-sdr.org

Thanks for your attention