A first look at the u-blox ZED-F9P dual frequency receiver

The new low cost dual frequency receiver from u-blox, the ZED-F9P, is just now becoming available for purchase for those not lucky enough to get early eval samples from u-blox.  CSGShop has a ZED-F9P receiver in stock for $260 which seems quite reasonable, given that it is only $20 more than their NEO-M8P single frequency receiver.

Even better, Ardusimple is advertising an F9P  receiver for 158 euros (~$180) + 20 euros shipping , although their boards won’t ship until January.  As far as I’m aware of, this is actually less than anybody today is selling the M8P receiver for today!

Of course, this is still a fair bit more than a u-blox M8T single frequency receiver without an internal RTK engine, which is available from CSGShop for $75, but the F9T will be coming out next year also without internal RTK engine, which should bring down the price for the lowest cost dual frequency receivers.

Unfortunately I am not one of the lucky ones who got eval boards directly from u-blox yet.  However, I do have two prototype boards from Gumstix, given to me by them for evaluation.  Gumstix offers both off-the-shelf boards and semi-custom boards designed from their libraries of circuits.  I haven’t worked with them directly but it looks like an interesting and useful concept.  The F9P boards from Gumstix won’t be available for sale until at least Feburary next year but I thought I would share the results of some initial testing.  From a performance perspective, I would expect these boards to be similar to F9P boards from other suppliers.

For a first look, I chose to compare the F9P to an M8T for one of my typical driving-around-the-neighborhood exercises.  I looked at both the internal real-time F9P solution and the RTKLIB solutions, both real-time and post-processed.

Experiment Setup:

For the base stations, I connected a CSGShop M8T receiver and a Gumstix F9P  receiver through an antenna splitter to a ComNav AT330 dual frequency antenna on my roof.  Since RTKLIB doesn’t yet fully support the receiver commands needed to setup the F9P, I used the most recent version (18.08) of the u-blox u-Center app run on a Windows laptop to configure the F9P receiver using the documentation on the u-blox website.  I then saved the settings to flash.  The receivers were connected to a laptop with USB cables and I broadcast the base observations over the internet on a couple of NTRIP streams using STRSVR and RTK2GO.com as I’ve described previously.  I configured the F9P to send RTCM3 1005, 1077, 1087, 1097, 1127, and 1230 messages which include base location, raw observations, and GLONASS biases.

For the most part the u-blox documentation is well written and this exercise was fairly straightforward, but I did run into a couple of issues.  First of all, when I plugged the F9P receiver into the laptop, Windows chose the standard Windows COM port driver instead of the u-blox GNSS COM port driver that it chose for the M8T receiver.  You can see this in the screen snapshot below where COM17 is the M8T and COM21 is the F9P.


Both drivers allow the user to set the baudrate in the properties menu available by right clicking on the device name.   With the u-blox driver, the baudrate setting doesn’t seem to matter which makes sense since it is a USB connection.  I have always left the u-blox driver baudrate at the default of 9600 baud without any issue.  With the windows driver, however,  I found that I had to increase the baudrate setting to 115200 to avoid data loss issues.  I have run into a similar problem before for sample rates greater than 5 Hz when the M8T is accessed through it’s UART interface and an FTDI converter is used to translate to USB, rather than communicating directly through it’s USB interface.  I verified though, that in this case the board is using the USB interface on the receiver and not the UART interface.   Not a big deal, and it may be unique to this board, but something to be aware of in case you run into a similar problem.

The second problem I ran into is that the F9P module seems to be sensitive to my antenna splitter, a standard SMA DC block and tee which I have used on many other receivers before without issue.  It works fine if the F9P power is blocked but if the M8T power is blocked, the F9P seems to detect the tee and shut off the antenna power.  Again, not a big deal, but something to be aware of.

For the rovers, I used a u-blox ANN-MB-00 dual-frequency antenna for the F9P receiver.  This is the antenna u-blox provides with its F9P eval units.  I had planned to split this antenna signal to both receivers as I usually do, but I ran into the problem described above, and not fully understanding the issue yet, ended up using a separate Tallysman TW4721 L1 antenna for the M8T receiver.  Both antennas were attached directly to the car roof which acted as a large ground plane.

I used a hot spot on my cellphone to stream the NTRIP base station observations from the phone to a laptop and then to the F9P receiver and to two instances of RTKNAVI, one for each rover receiver.

Streaming the base observations to the F9P, while simultaneously logging the internal RTK solution and the raw rover observations, and also sending the raw rover observations to RTKNAVI, all over a single serial port can be challenging since only a single application can be connected to the serial port at one time.  Fortunately RTKLIB has a little trick to deal with this.  If the “Output Received Stream to TCP Port” box is checked in STRSVR and a port number specified as shown below, all data coming from the other direction on the serial port will be redirected to a local TCP/IP port.  This data  can then be accessed by any of the other RTKLIB apps as a TCP Client with server address “localhost” using the specified port number.


I set up the F9P rover to output both raw observation and navigation messages (UBX-RXM-RAWX/ UBX-RXM-SFRBX) and solution position messages (UBX-NAV-POSLLH).  RTKNAVI then logged all of these messages to a single log file.  RTKCONV and RTKPLOT can both extract the messages they need from this file and ignore the rest so combining them was not an issue.

The POSLLH messages from the F9P default to a resolution of 1e-7 degrees of latitude and longitude which works out to roughly 1 cm.  For higher resolution you can use the POSHLLH message or you can increase the resolution of the POSLLH message by setting a bit in the UBX-CFG-NMEA message.   RTKLIB only understands the POSLLH message so that is what I used.  Unfortunately I did not realize the resolution issue until after I collected the data and so my results for the internal F9P solution for this experiment were slightly deteriorated by the lower resolution.

I used the most recent demo5 b31 code to calculate all of the RTKLIB solutions.  Both the demo5 and the 2.4.3 versions of RTKLIB have been updated to translate the new dual frequency u-blox binary messages.  The demo5 solution code will process all the dual frequency observations but I don’t believe 2.4.3 code is able to process the E5b Galileo measurements yet.  The RTKLIB 2.4.2 code however does not have any of these updates.

The demo5 code updates made in the recent B30/B31 versions are based on the updates from the 2.4.3 B30 code but include some modifications to the u-blox cycle slip handling that I had previously added to the demo5 code for the M8T.  Since the demo5 code is primarily aimed at low cost receivers I also made some changes to make the E5b frequency a little easier to specify and faster to process.

To run the RTKNAVI F9P real-time solution, the only significant change I needed to make to the default M8T config file was to change the frequency option from “L1” to “L1+L2+E5b”.  I should have also changed the base station position to “RTCM Antenna Position” to take advantage of the F9 base station RTCM 1005 base location messages but neglected to do this.  This caused the RTKNAVI solution to differ from the F9P solution by small constant values due to the approximate base location used in the RTKNAVI solution.  I later used exact base locations for the RTKLIB post-processing solutions to verify that the different solutions did in fact all match.

Once I had everything set up, I then drove around the local neighborhood, emphasizing the streets with most challenging sky views since I knew both receivers would perform well and be difficult to distinguish if the conditions were not challenging enough.


I first converted the binary log files to observation files using RTKCONV and verified that the F9P was logging both L1 and L2 measurements for GPS, GLONASS, and Galileo.  I had the Bediou constellation enabled as well but as I verified later, there were no fully operational Bediou satellites overhead when I collected the data.

Here is an plot of the L1 observations for the M8T on the left and the F9P on the right.  I have zoomed into just two minutes during some of the more difficult conditions to compare the two.  The red ticks are cycle slips and the grey ticks are half cycle ambiguities.


First, notice that the F9P does not log observations for the SBAS satellites, while the M8T does, giving the M8T a couple more satellites to work with.  However, what’s also interesting, and I don’t know why, is that the F9P collected quite good measurements from the Galileo E27 satellite, while the M8T did not pick up this one at all.  Of course the F9P also got a second set of measurements from the second frequency on each satellite and so overall ended up with nearly twice as many raw observations as the M8T.

Also notice that the F9P reports somewhat less cycle slips and many less half cycle ambiguities than the M8T.  Some of this might be because of the different antennas, but particularly the large difference in half cycle ambiguities suggests that u-blox has made other improvements to the new module besides just adding the second frequencies.

Another thing to notice is the number of Galileo satellites.  If you compare these plots to earlier experiments I’ve posted, you’ll notice there are more Galileo satellites now as more and more of them are starting to come online.  The extra satellites really help the M8T solutions because as you can see, they tend to have the highest quality observations through the most difficult times.  Again I don’t know why this is.  It doesn’t appear to be as true for the F9P though.

Next I looked at the real-time solutions.   First, the RTKLIB solutions with RTKNAVI for both receivers.  For the full driving route, the M8T solution had a 77.3% fix rate and the F9P solution had a 96.4% fix rate.  Here is a zoom into the most challenging part of the drive, an older neighborhood with narrower streets and larger trees, the M8T is on the left, and the F9P on the right.  Fixed solutions are in green and float in yellow.  Clearly here the F9P significantly outperformed the M8T.


The F9P internal solution did even better with a 99.2% fix rate, as shown in the plot below.  All three solutions agreed within 2 cm horizontal, a little more in vertical, and none of them showed any sign of any false fixes.


I didn’t do any static testing to characterize time to first fix as I sometimes do, but for this one run the RTKLIB time to first fix for the M8T was 18 seconds while the RTKLIB F9P solution reached first fix in 6 seconds.  In both cases, RTKLIB was started after the hardware had time to lock to the satellites and acquire navigation data for all satellites.  The demo5 RTKLIB code has an additional fix constraint based on the kalman filter position variance to minimize false fixes while the filter is converging and so this can sometimes affect time to first fix.  I had increased this parameter to 0.1 meter for this experiment since the large number of measurements reduces the chance of a false fix.  This constraint did not limit the M8T time to first fix but it did so for the F9P, meaning the F9P would have reached first fix even faster if this constraint were opened up more.   I can’t tell what the equivalent number would be for the internal F9P solution from this data since it had already been running and achieved a fix before I started logging the data but generally the F9P seems to acquire first fix very quickly.

Next I post-processed both data sets with RTKLIB using the combined-mode setting to run the kalman filter both forwards and backwards over the data.  This noticeably improved the results, bringing the fix rate for the M8T up from 77.3% to 96.1% and the F9P fix rate from 96.4% to 98.8%.



Obviously this is not enough data to make any definitive conclusions, but so far I am very impressed with the F9P!  Both the raw observations and the internal RTK solutions for the F9P look as good as anything I’ve seen from receivers costing many times what this one cost.

If anybody would like to look at the data from this experiment more closely, I have uploaded it to here.  I should mention that all the fix rates I specify in this post and other posts won’t exactly match the fix rates in the raw solutions, since I adjust the data start and end times to be consistent between data sets and to start after all solutions have achieved first fix.  I believe this is the fairest way to compare multiple solutions, especially when there is a mix of internal and RTKLIB solutions

Also, I’d like to thank Gumstix again for making these modules available to me for evaluation!


Update: 12/2/18:

Reviewing the config files I used for this experiment I discovered that, while I had intended the real-time and post-processing config files to be identical, there were in fact some small differences between them.  One difference in particular, that appears to have affected the results as described above, is that I reduced the minimum number of consecutive samples required to hold ambiguities (pos2-arminfix) from 100 to 20 for the post-processed config files.  A value of 100 corresponds to 20 seconds at the experiment’s 5 Hz sample rate which is a value I have typically used.  However, with lower ambiguity tracking gain (pos2-varholdamb=0.1) and the increase in observations coming from including Galileo, the chances of false fixes is reduced and I have been tending to use lower values of arminfix in more recent experiments.   Reducing this value appears to explain a large part of the jump in percent fix for the M8T between real-time and post-processing, rather than the switch from forward-only to combined that I attribute it to above.  These differences only affect the comparisons between RTKLIB real-time and post-processed results, and not between the M8T and the F9P since the config files were consistent between the two receivers.

This was only intended to be a quick first look at the F9P.  It will require more data and more analysis to properly characterize the F9P so I  won’t try to do that here but I will share the table shown below which includes a few cases I have run since the original post.  I hope to dig into the details in future posts.

Fix percent
Real-time Post-process Post-process Post-process
forward-only forward-only forward-only combined
M8T/RTKLIB 77.3% 81.2% 96.0% 96.1%
F9P/RTKLIB 96.4% 99.1% 99.3% 98.8%
F9P internal 99.2%

One last point worth making is that while at first glance the post-process fix percent increase from M8T=96.0% to F9P=99.3% may not sound that significant, it is in fact a factor of nearly six if you consider it as a decrease in float from 4.0% to 0.7%.


47 thoughts on “A first look at the u-blox ZED-F9P dual frequency receiver”

  1. Further checks confirm the internal fix for the F9p typically <30 seconds vs rtklib fix in 5 minutes again over a chalenging 43 km baseline. RTKlib reports 22 satelites valid (snr mask default all 0) in partial sky view, but interestingly F9p reports maximum 12 satelites valid but never more ( sometimes less on initial switchon) possibly the F9p is only using the very best satelites ( for its solution) and ignoring the inferior ones once it has got 12 best valid satelites. That might explain the fast fix given the good solid data that the F9p is using vs rtklib. Interestingly by tweaking the snr mask values in rtklib to a very specific 44db L1 and 38db L2 gave me also around 12 satelites valid in rtklib and a much improved fix time there, comparable, but still not quite as fast as the F9p internal one. However using these snr mask values in practice would not be good idea as it could lead at times to few satelites at times. The internal solution is probably better in choosing the best 12 satelites based on some possibly other criteria. Just my initial thoughts on this fantastic product.


    1. Hi Anthony. It’s an interesting observation that the F9P appears to be using only 12 satellites. If you want to limit the solution to only the best satellites, it might work better to adjust the elevation mask than the SNR mask, especially if you want the config to be more tolerant to different antennas or receivers. However it would still not be the same as only using the x best satellites.


  2. Hi Tim, Great post as usual! I hooked up my Ardusimple ublox F9P using your guide and trick with STRSVR ( so STRSVR inputs Ntrip and outputs to F9P while echoing F9P outputs to tcp-ip server, never realised before that could SRTSVR work both ways like that. I have used it before to echo inputs to tcp-ip before though.)
    Very fast fix using internal RTK, much faster that RTKlib running at the same time. Using a 43 Km baseline to nearest Eu-ref base (SHOE00GBR0) with the base outputing Gps,Glo, Gal, Bei. Maybe my long baseline is why your RTKlib fixes are faster on your short baseline.
    RTKlib signal bars show Gal E5b signals received but the RTK monitor window does not list any E5b signals?? I guess its using them though? Anyway with all those satelites and frequencies the performance was stunning, even in partial view of the sky.
    One minor problem with STRSVR though it hangs when F9P powers down and back up again (ie lost COM port) A minor nuisance but annoying. Ideally in use it should automatically recover from that.. ( Note to self might try different timeouts in STRSVR)
    I plan to hook up an HC05 bluetooth using the XBee sockets to make it easier to use in practice. It should also get rid of the usb driver problem in windows 10.


    1. Hi Anthony. I have not done comparisons with long baselines between RTKLIB and the internal F9P RTK solution but am not surprised that the F9P did better than RTKLIB because I think u-blox is specifically targeting solutions that don’t require local or virtual base stations. To include the E5b signals in the demo5 solution, you do need to set the frequency option to “L1+L2+E5b”. You can verify if E5b is being used in the solution by enabling residuals and plotting them with RTKPLOT, or by looking in the trace file. I have not seen the problem with STRSVR that you describe but I will be on the lookout for it now.


  3. I notice you mention csgshop on the site. I wonder if you get tracking numbers soon enough when you order form there.

    I ordered something, it took a week to respond they shipped and they didn’t provide a tracking number.


    1. Hi Epigramx. On my most recent order to CSG Shop in Jan, I see that I got separate email updates from them when they got the order, received payment, processed it, and shipped it, but no tracking number even though the last email said I should be receiving one. Shipping from them can take several weeks, at least to the U.S.


  4. Hi, I’ve just ordered the Ardusimple F9P board with the plan to eventually do corrections off-line (i.e. post-processing). Are there any considerations to take into account for that? Will it have the same output as real-time?


    1. Hi Joren. You will not be able to post-process data with the F9P but you can log the raw observations and post-process them with RTKLIB. The post-processed results from RTKLIB will be similar to what you would have got real-time from the F9P.


    1. Hi Adam. Yes, I have tried PPP with the F9P raw data, both with an SSR solution and submission to an online PPP solution. Both looked good and similar to Swiftnav results that I have previously posted. In general, I was only able to take advantage of the GPS and GLONASS measurements, not the Galileo, or Beidou for these solutions. I’ll try and do a future post on PPP solutions with the F9P.

      Liked by 1 person

      1. Hello rtklibexplorer and followers,
        I did some test with a ardusimple F9P paired with their (very) inexpensive antenna process on the PPP application of RNCAN (2 hours rinex from ubx datas) and the final result was a difference 2cm in N and 1cm in E against those obtained with a surveying Trimble R8 .
        The precision for the Z is less since the APC and ARP of the antenna are unknown

        Liked by 1 person

  5. Nice write up!
    Anyone tried to connect the F9P (using internal RTK) to a Arduino MCU or similar device and would like to share their experience? Any settings or post-processing needed to be done? I really like the concept of an internal RTK since without the need of running Linux and RTKLib it’s now available for even smaller and less powerful IOT-devices.


    1. To use internal RTK – you just need to send RTCM3 messages from base station to the rover’s receiver, without any pre/post-processing (simple read bytes from base you set up and write to the rover). If your arduino can receive messages from base by some way then you’re ok. Almost.

      Slight problem can be parsing NMEA’s messages to get full precision and determine the RTK’s status. I’ve patched the TinyGPS++ library to read the quality field from G*GGA messages (you may check TinyGPS++.h/cpp files from my https://github.com/vasimv/rtkzedf9p ), but there is big restriction for using the code on the arduinos – most of 8-bit arduinos have 4-bytes double data type (same as float) and you will lose the precision on those (will be about tens of centimeters maximum). You’ll need to write your own NMEA parser or use 32-bit arduinos with 8-bytes double, like Arduino DUE.


  6. I have a f9p (from ardusimple).
    I would like to use rtknavi as ntrip client and “output received Stream to TCP Port”. But this dont work in rtknavi. With strsvr it works fine. But strsvr cant send a position to the VRS, so i need rtknavi.

    Any Idea why the output is not working in rtknavi? Any solution?

    Thx! Keep on with your great work here!


      1. i really cant figure out why it doesnt work with rtknavi. every setting is the same. i tried different demo5 versions (b26 to 31) on 2 different PCs. But still the same result.
        Can you test if the “output received Stream to TCP Port” is working in rtknavi? Can you fix it in rtknavi? i dont have the coding abilitys to fix this by myself.

        Liked by 1 person

        1. Hi Christoph. Do you see the same problem with the official 2.4.3 RTKLIB code or is this unique to the demo5 code? If you can first try the 2.4.3 code then run the demo5 code with the debug trace option set to level 2 and send me the trace file and the configuration file you used, I will take a look at it.


          1. i just tried the official 2.4.3, but still the same issue. strsvr works fine, rtknavi dont stream anything from the serial port to tcp :/


          2. Solved problem: downloaded Tim’s f9_navi.conf and tweaked it for my simpler installation. Now I am getting a solution in RTKLIB. Thanks a lot. I now need to look at what is different and WHY it works now and not before.


    1. Hi Aleksandr. The config file is used to configure RTKLIB, not the receiver. The command files is used to store receiver setup commands but RTKLIB does not yet fully support the setup messages for the F9P so this is not an option right now. That is why I used u-center to configure the F9P. I followed the instructions from u-blox to do this.


      1. Ah, in u-center v18.11, I think I found the configs under View/Generation 9 Configuration View/Advanced Configuration/CFG-MSGOUT/… etc.. Still fiddling.


        1. Hi drf. Yes the new version of u-center uses the “Gen9 Config View” to program the receiver registers but you can still access the old-style configuration menu through the “Messages View” by selecting the UBX->CFG messages. The u-blox documentation for the F9P is posted now to their website and is quite good.

          Liked by 1 person

        2. Note to self: in “I configured the F9P to send RTCM3 1005, 1077, 1087, 1097, 1127, and 1230 messages which include base location, raw observations, and GLONASS biases. ” RTCM3 1005 is the station position, 1077-1127 are the GPS, GLONASS, Galileo, and BeiDou MSM7 (Multiple Signal Messages type 7) messages, and the 1230 is the GLONASS biases.


  7. did mine receive from csg shop today..

    looks very interesting..
    the only problem i have that i can not store some settings at the receiver (eg. rate)…

    i did try ubx>cfg>cfg and save settings in receiver >action>save


    1. The ZED-F9P module has a different configuration interface than the M8/7/6 series modules, read the interface manual to find out the details. The generation 9 modules do not completely support the ubx>cfg>cfg interface, so sending commands via RTKLib won’t always work.


  8. I´m soooooo ready for the F9P, I´m one of the backers of ArduSimple Kickstarter campaign.. Tim, to use the internal RTK, are there any special commands to activate it ? Are there any pros/cons to use the internal vs RTKlib ?


    1. The u-blox documentation is quite good for the F9P, and details what you have to do to get the module into “base station” mode. The ArduSimple modules will come pre configured for either Rover or Base depending on what you ordered. It is easy to switch between them though.
      RTKlib requires and external computer to do the RAW + RTCM3 to position calculations, there are use cases for both using RTKlib and standalone.
      I have to concur with Tim that out of the box, the F9P is quite the performer, and in quantity, the bare modules are very competitive price wise with the M8P.


    2. Internal RTK works much faster (not sure about quality, but looks not worse than RTKLIB at least), catches fixes in seconds after losing it while RTKLIB requires a lot of time to restore it.

      I’ve made simple utility to use the internal RTK – https://github.com/vasimv/rtkzedf9p , but it doesn’t include configuration as i’ve made it all through u-center on both receivers. You have to enable all RTCM3 messages on baase’s port connected to the tcp/ip (through ser2net or similar port redirector) , disable NMEA messages on the port and configure TMODE right (specify the base’s coordinates or switch it to survey mode so it’ll try to determine them at start by averaging). On rover – just enable RTCM3 input and RTK if you did disable it (was enabled by default if i remember correctly).


      1. Interesting! I have just received two ArduSimple Z9P boards, and started to play with L1+L2+E5b on RTKLIB.
        I will for sure take a look at the tool you have created!


      2. Hi Vasim. I agree that the F9 internal solution is very good but I did not find that the RTKLIB solution took a long time to restore after losing a fix. For example, for the data in this post which was taken in moderately challenging conditions with a moving rover, I don’t think it ever took more than 5 seconds to restore fix after it was lost and was typically only 2 or 3 seconds. Are you using the demo5 code? Did you verify that your solution is including all constellations and frequencies?


        1. Of course, may be i did something wrong with rtkrcv settings, most of its stuff is rocket science for me. I’ve used about same settings as for M8T which i’m using on my lawnmower (except i’ve switched to RTCM3 from base instead u-blox raw). Didn’t disable anything, just set 35dbm as minimum signal and 20 degrees in the filter, all enabled (gps, glonass, baidu, etc). Btw, if i understand U-blox settings correctly, it uses 6dbm to filter satellites, the RTKLIB doesn’t work good with that, perhaps it has some kind of additional filtering. Yes, i was using your latest version of the RTKLIB.

          I did testing with L1 antennas only (L1+L2 dual band antennas on the way to me yet). When i was walking under large trees – rtkrcv had quite longer time to find and restore fixes after moving out, while internal RTK did sometimes in one its cycle (0.5 seconds). Also, i’ve wrote full track with ZED-F9P in RTK mode on moving golf cart with constant speed ~23 km/h and checked it later – it took at most 20 seconds to restore fix after driving through area where sky is blocked by trees.


          1. Tried L1/L2 antennas (Tallysman TW3865) with internal RTK, looks better. Not much but gives some fix stability under trees and other obstacles. Although, doesn’t look like worth it if use ZED-F9P on open space only, Tallysman TW2710 (L1 only and two times cheaper) gives about same perfomance on open areas.


        2. Tim, more and more people are getting the Z9P ( I just got two ArduSimple receivers), do you think you can write a small post about the best settings in your opinion for our new L1,L2 and E5b receivers ?


          1. Hi Carl. I posted the config file I used for RTKLIB with the F9P with the raw data here. This should give you a good dual-frequency solution including L1, L2, and E5b with RTKLIB. For the F9P base and rover receiver settings, I just followed the configuration instructions in the u-blox F9P integration manual for the internal solution and enabled the raw observation and navigation messages for the RTKLIB raw data as I would for the M8P. The u-blox documentation is quite complete and fairly easy to follow.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.