LPS Mini

Arduino compatible indoor navigation system with small form factor.

Similar projects worth following
LPS Mini - Local Positioning System in a very small form factor. Indoor navigation system with 10 cm precision. Higher precision can be achieved using on-board sensors for inertial navigation. Arduino Nano compatible (not a shield), except that some signals are used internally.

Outdoor range: Around 200-300m line of sight depending on your propagation environment.
Indoor range: Around 30-50m depending on your walls.
Update rate 1-10 Hz depending on your application.
Accelerometer/Gyro/Compass: MPU-9250.
Altimeter: MS5611-01BA03.
Battery (optional, not included): Most small LiPo cells will do.
LiPo Charger: MCP73812T-420I/OT.
Solder pads for address setting and configuration.
8-bit ATMEGA328-MUR MCU.
Crystal: Used to be 8 MHz, now upgraded to 12 MHz.
Mates with TE Connectivity 5650712-1 to give easy access to all I/O (optional).
3.3V logic levels.
Size: 29x28 mm.
Weight without battery: 4g.

How do you tackle indoor navigation so accurate that you can keep a robot in a confined area? We needed to complement dead reckoning with an absolute sensor. Like GPS but indoors and with a higher accuracy. The same problems exist in GPS denied environment or where the GPS is just not reliable enough. A lidar could be used against an existing lidar map or with landmarks identified in some way. But we wanted an alternative. Thus, absolute location without GPS: Local Positioning System (LPS).

The project is centered around the DW1000 chip - an ultra wide band radio chip from DecaWave. This chip has excellent reflection and second path rejection and do (for most of the time) give you the shortest distance between two of the nodes. Using one or a few nodes (tags) on the thing we want to locate and a number of stationary nodes (anchors) of known location we can get the distance between each tag-anchor nodes. This is the same way that GPS works - by estimating the distance between the GPS receiver and the different satellites. From these distances, or ranges, we can estimate the location. Combined with inertial and dead reckoning you can get a very good estimate over time of where you are located relative to the anchors.

  • 1 × ATmega328P-MUR Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × MPU-9250 Nine-Axis (Gyro + Accelerometer + Compass) MEMS MotionTracking Device
  • 1 × MS5611-01BA03 Barometric Pressure Sensor, with stainless steel cap
  • 1 × MCP73812T-420I/O T Power Management ICs / Power Supply Support
  • 1 × LP3982ILD-3.3/NOPB Power Management ICs / Linear Voltage Regulators and LDOs

View all 6 components

  • We are now shipping LPS2 Mini and Blueberry!

    Göran Nordahl05/15/2017 at 12:45 0 comments

    Here comes some updates regarding our LPS and Berry product families!

    ==== Short version for existing customers ===
    * We are now shipping LPS2 Mini and Blueberry! With the boards you will get demo software to access the sensors and, in the case of the LPS2 mini, Two Way Ranging (TWR) capability. The software is not written for the Arduino IDE like our previous generation of boards, but instead in C using the Nordic SDK for the nRF52 and compiled with GCC. We can also provide Python drivers for ROS. More advanced features such as TDoA and wireless distribution of clock and sync to be sold separately.
    * HW for building wired networks for distribution of clock and sync is in the making.

    === Long version for both old and new customers ===
    There are three main principles when measuring distance and figuring out a position using radio: Received Signal Strength Indication (RSSI), Time of Flight (ToF) and Angle of Arrival (AoA).
    * RSSI is simple, but suffers from severe problems as soon as the signal path is blocked and attenuated. BLE beacons use this technique, making them ideal for cheap proximity sensors, but not good enough for navigation.
    * ToF measures the time it takes for a radio wave to travel a distance at the speed of light. This requires complex hardware, but is a lot more reliable than RSSI. By using extremely short transmissions/pulses, reflections in nearby objects will not overlap with the direct wave at the receiver. This will, in theory, prevent the effects of so called multipath fading. Transmitting short pulses is the equivalent of using a very wide bandwidth, hence the name Ultra WideBand radio (UWB).
    * AoA requires more than one antenna to figure out the direction of the incoming wave. Contrary to RSSI and ToF it reports an angle, not a distance. This method has been extensively used for naval navigation, where a ship takes bearings to known radio beacons.

    No matter the method in use to do the actual measurements, a position in space can be calculated using a geometrical process called trilateration. Adding filters to the process will further improve the result. All this functionality is often integrated in a so called location engine.

    ToF can be put to work using three main principles: Two Way Ranging (TWR), Time Difference of Arrival (TDoA) or Reverse TDoA (RTDoA):
    * TWR is a simple method performed point to point between a moving tag and one or several anchors acting as reference points with known positions. TWR works well when tracking a limited number of objects, but the update rate decreases the more tags asking around for distances. This was our initial approach and is used with our robot beds: If you are in Oslo you can take a look at them here:å-henie-onstad-kunstsenter
    * In its pure form TDoA has tags that only transmit and anchors that only listens. Anchors collect and sends time stamped UWB packages to a central server, where a location engine compares the different arrival times and calculates tag positions. With many active tags, collisions will occur putting an upper limit to the throughput and number of active tags in a TDoA system. Some kind of synchronization also among tags can thus be useful to achieve highest possible update rate and number of active tags. The problem is that reception costs more power than transmission, so enabling the receiver once in a while to get synchronization packages has a negative impact on tag battery life. TDoA is well suited for tracking people in offices: Lowest possible power consumption combined with large number of tags.
    * In RTDoA things are turned on its head. Synchronized anchors transmit packages one after another and tags listen. The location engine is run locally in each tag. Such a set-up has no upper tag limit and has the lowest possible latency for the tag to know its own location, to the cost of using the power hungry receiver instead of the transmitter....

    Read more »

  • LPS2 PCS in production!

    Göran Nordahl04/11/2017 at 08:09 0 comments

    This is how LPS2 PCS turned out:

    Here in red together with LPS2:

    The first hand built prototypes will be ready in 1-2 weeks. Next up is designing HW for the clock and sync distribution network. LPS2 PCS is just the endpoint.

  • LPS2 PCS preview

    Göran Nordahl04/03/2017 at 12:12 0 comments

    Here is a preview of our upcoming LPS2 PCS board (PowerClockSync). It is intended as an add-on to LPS2 with the following features:

    * Power supply via PoE or wall adapter.

    * Ethernet (10/100 Mbps) as a complement to the optional WiFi on LPS2.

    * Receiver for clock and sync via spare twisted pairs in the ethernet cable.

    * Jitter cleaner for received clock.

  • New LPS boards and a little Blueberry soon in production!

    Göran Nordahl02/02/2017 at 11:20 1 comment


    We have four new boards soon to be sent to production: LPS^2, LPS^2 Mini, LPS RPi and Blueberry:

    === LPS^2 ===
    * First board of our new LPS^2 family.
    * nRF52 as MCU, i.e. ARM Cortex M4F.
    * USB.
    * BLE.
    * Can act as RFID tag (untested).
    * Optional WiFi.
    * DW1000 for UWB.
    * Clock and sync handling/distribution for TDoA/AoA
    * Accelerometer, gyro, compass, altimeter, thermometer.
    * TCXO to eliminate the thermal drift of DWM1000.
    * Optional external FLASH for data storage.
    * LiPo charger with power either from USB or a small solar panel.
    * Size: 34x52 mm, but it will most likely be a little wider in the production version.

    === LPS^2 Mini ===
    * Second board of our new LPS^2 family.
    * nRF52 as MCU, i.e. ARM Cortex M4F.
    * USB.
    * BLE.
    * Can act as RFID tag (untested).
    * DWM1000 for UWB.
    * Accelerometer, gyro, compass, altimeter, thermometer.
    * LiPo charger with power either from USB or a small solar panel.
    * Size: 25x30 mm.

    === LPS RPi ===
    * Plug-in board for Raspberry Pi. We see this board as a cheap way to try out DWM1000 and as a tool for analysis.
    * DWM1000.
    * DIP for address setting.
    * Altimeter.

    === BLUEBERRY ===
    * First board of our new family of small berries.
    * A bit like LPS^2 Mini without UWB and USB, but with more sensors. Can e.g. be used for motion analysis or as a weather station.
    * nRF52 as MCU, i.e. ARM Cortex M4F.
    * BLE.
    * Accelerometer, gyro, compass, altimeter, thermometer, RH, light, UV + a few I/O.
    * Battery holder for CR1632.
    * Size: 20x20 mm.

    === CRANBERRY ===
    *** Exists as HW prototypes, but does not yet fully work. Something in the strain gauge interface consumes too much power. Only listed here as an example of an upcoming board. ***
    * Second board in our new family of small berries.
    * Identical to Blueberry, except that it also handles strain gauges, has a larger battery and thus also larger size.
    * Battery holder for CR2032.
    * Size: 26x26 mm.

    === CLOUDBERRY ===
    Does only exist in CAD, not yet as a physical prototype. Intended to connect both the Berry and LPS^2 families to the internet using either WiFi or LoRa. Might also have the option of GSM, depends on customer need.

    We would like to probe your interest in these boads, and if possible, receive pre-orders for the ones soon to be sent to production (LPS^2, LPS^2 Mini, LPS RPi and Blueberry). Pricing will depend a bit on the initial production volume. We do not yet know their final price, but Blueberry and LPS RPi will be cheapest and LPS^2 and LPS^2 Mini somewhere around the price for our current LPS boards. Possibly with the exception for a fully equipped LPS^2 (WiFi, extra FLASH, etc) that will cost more. We do not want any money up-front, but really would appreciate very quick payment after shipment. That way we can afford paying the factory in time… :-) We estimate a delivery time of 4-6 week for all boards except LPS^2 that will take a little bit longer (something like 8 weeks).

    If you have not yet reached your weekly youtube limit, here is a little video showing our test rig for Angle of Arrival (AoA):
    Some explanations:
    * Distance between receiver boards (two modified LPS boards to handle external clock and synk + better antenna) is 300 mm.
    * The x axis shows time.
    * The y axis shows difference in distance to the tag.
    * The blue dots are individual measurements and the green line is the mean value.
    * Both TDoA and TOF can be used, i.e. both angle and distance to the tag can be measured.
    * In the bottom of the screen values for TDOA, TOF (if enabled) and RSSI are shown.
    * At 0:20 a slider in the web interface controls the rig orientation. Much easier to rotate the rig than running around with the tag....

    Read more »

  • Cranberry

    Göran Nordahl12/23/2016 at 13:16 0 comments

    Yet another little board based on LPS^2 Mini (but without UWB) is ready for the factory! Cranberry has the same features as Blueberry (BLE/acc/gyro/compass/altimeter/RH/temp/light/UV), but can also handle up to four strain gauges / load cells! Size 26x26x9 mm, compared to 20x20x6 mm for Blueberry. Battery size CR2032 instead of CR1632.

  • LPS^2 prototypes in the lab

    Göran Nordahl12/19/2016 at 10:58 9 comments

    LPS^2 prototypes just arrived! No smoke at power-up. Next step is the HW equivalent of "Hello, World!", i.e. flashing a LED.

  • What is not in the CAD is solved with patch wire

    Göran Nordahl12/14/2016 at 09:56 0 comments

    Ooops, missed connecting UART to the USB chip on the LPS^2 Mini prototypes. With help of some patch wire all HW now seems to be fully functional.

  • 3D printed test jigs for LPS^2 Mini and Blueberry

    Göran Nordahl12/14/2016 at 09:41 0 comments

    11 LPS^2 Mini are assembled and do not produce smoke when powered up. In a few days Blueberry PCB:s will arrive to the lab. We are prepared with 3D printed test jigs!

  • LPS^2 Mini - UWB = Blueberry

    Göran Nordahl12/10/2016 at 21:07 1 comment

    A stripped down version of LPS^2 Mini (no UWB) will be sent to the factory on Monday. Main features:

    * Cortex M4F (nRF52832).

    * BLE, ANT or your favourite home made ISM protocol for 2.4 GHz.

    * Accelerometer, gyro and magnetometer: MPU-9250.

    * Altimeter/barometer: LPS22HB.

    * UV and ambient light: Si1133.

    * RH and temp: HTS221.

    * Two GPIO.

    * Battery holder for CR1632.

    * Size: 20x20x6 mm including battery.

    More info:

    Blueberry can for example be used as a tiny weather station or IMU.

  • First LPS^2 Mini prototype

    Göran Nordahl12/06/2016 at 19:08 0 comments

    The first LPS^2 Mini prototype passed first HW tests! No smoke when applying power and the MCU can talk to its sensors! Now we will assemble more of them in our lab and write a Board Support Package (BSP). Stay tuned for updates! :-)

    Prototypes of LPS^2 are currently being assembled in a factory. Looking forward to test also them!

View all 38 project logs

  • 1
    Step 1

    Configure the boards to be tag/anchor and give them individual addresses. J8 decides tag(1)/anchor(0) and J4-J1 sets the address. A tag and anchor can have the same address since tags and anchors are handled separatley. J7-J5 is not used by our demo software, but can of course be used either for configuration or more address space. If you are not fond of soldering it is just to store the configuration in EEPROM instead. Just a matter of code.

  • 2
    Step 2

    Normally a tag reports measurements via UART. By adapting the firmware also I2C/SPI can be used, but that will decrease the update rate due to bus bandwidth limitations. In this example we are using the UART connected to a USB to TTL converter. 3.5-5V is supplied by connecting a LiPo battery or power supply directly between +BATT and GND. The 5V pad is used to charge the LiPo and is of no use if using an external power source.

    The serial interface and power connections are also available via the board edge connector.
  • 3
    Step 3

    An anchor do not need to report anything to an external MCU, so it only requires power.

View all 5 instructions

Enjoy this project?



Edison Lin wrote 07/07/2017 at 10:32 point

Hi Göran,

I'm studying dwm1000.

Can I ask a question about antenna gain of dwm1000,

What its antenna gain is?

I don't know where to find the answer. :(

Thank you. 


  Are you sure? yes | no

s.embree wrote 12/06/2016 at 19:49 point

Göran, do your latest generation of LPS boards ship with embedded code that can do TDOA?  If so, is the time synchronization of anchors included in that code?  

  Are you sure? yes | no

Guillermo wrote 11/27/2016 at 19:16 point

Hi Göran, It would be possible to use this project to automatically direct a lawn mower in an area of 200m. The idea is to delimit an area and program the route of the equipment. Automating this task unattended.

  Are you sure? yes | no

David Pammenter wrote 09/23/2016 at 11:51 point

Hi Göran, you will have to excuse my lack of knowledge in this field. reading down the thread and the info on crosstalk.  I am looking at a project that involves  tracking lots of people (150 or so) indoors. I would probably be ok with a tag read every two seconds or so. I take it this would not be possible as the crosstalk would be horrific? 



  Are you sure? yes | no

Göran Nordahl wrote 09/23/2016 at 12:05 point

Hi David,

Our current way of doing it (Two Way Ranging - TWR) can not handle that many tags with high update rate. With TDOA (Time Difference of Arrival) it is possible. We are working hard on a new generation of anchors able of both TDOA and AoA (Angle of Arrival).

  Are you sure? yes | no

Jeremiah Johnson wrote 10/27/2016 at 20:07 point

Ooh, TDoA & AoA?  Can you share the hardware you're using?

  Are you sure? yes | no

Göran Nordahl wrote 11/11/2016 at 09:02 point

Jeremiah for some reason I can not reply directly to your comment. The answer can be found here:

  Are you sure? yes | no

Anthony Hill wrote 05/10/2016 at 16:41 point

Are you releasing the source code for these? 

  Are you sure? yes | no

Göran Nordahl wrote 05/11/2016 at 17:36 point

Hi Anthony,

All our customers receive a source code package for free.

  Are you sure? yes | no wrote 02/22/2016 at 23:41 point

Where can I purchase some of these please?

  Are you sure? yes | no

ProjectAmber wrote 01/18/2016 at 07:06 point

Nice work. How about the communication latency? With 10 bytes in 1 packet, I've got around 10ms with XBee-Pro and 3ms with XBee-WiFi. I wonder if i could get latency under 1ms with DWM1000?

  Are you sure? yes | no

Göran Nordahl wrote 01/21/2016 at 14:28 point

My colleague Niklas says: Look at the attached table. As you can see a POLL with 13 bytes takes 176.6 µs @ 6.81 Mbps. To transfer 10 bytes in shorter time than 1 ms seems thus possible :-)

  Are you sure? yes | no

ProjectAmber wrote 01/26/2016 at 02:10 point

Thanks Göran. That's pretty cool and I thought it might be much stabler than XBee-WiFi becasue the 2.4G frequency is very crowded. Gonna try it.

  Are you sure? yes | no

Bryan Teague wrote 12/17/2015 at 21:26 point

Hi Göran. Really neat project! I'm toying with the idea of a DWM1000/RPi project myself and wanted to double check my notes with yours. You list 4 "bad ideas" from your quick and dirty test with the Raspberry Pi. I have not worked with RPi GPIO before so I'm trying to cover my bases by comparing my research with your firsthand experience. Here what I've found in relation to your 4 bad ideas:

1) I agree no ground plane will probably affect antenna performance.

2) DWM1000 has some decoupling caps under the shield, doesn't it? Are more required?

3) I thought RPi GPIO was 3.3V. Does this not apply to SPI pins? (

As a separate issue it seems like the 50mA supplied by RPi 3.3V is not enough to power the DW1000. The datasheet seems to indicate the absolute max current draw is closer to 350mA. Did you use a separate supply or a level translator from the RPi 5V?

4) I have not worked with RPi interrupts before, but would using something like the wiringPi library ( help improve interrupt handling or is that still polling under the hood?

  Are you sure? yes | no

Göran Nordahl wrote 12/20/2015 at 21:01 point

1: :-)

2: Decoupling: look at the recommendations in the DWM1000 and DW1000 data sheets, or ask Decawave directly. This is how DWM1000 looks under its RF shield:

As you can see there is some decoupling, but we noticed that it helps adding a bit more. We have mostly used the 110 kbps setting with long preamble to get as long range as possible, to the cost of higher power consumption. If using the 6.8 Mbps setting combined with short preamble the power consumption drops —> less need for bulk capacitance.

3: 5V I/O: Ah, you are correct. The 5V problem was encounter later on when we did our first Nano clone, i.e. the one called RadioBeacon. I have now removed the note about 5V from the RPi section, so now there are only three bad ideas left :-)

3.5: Try with large bulk capacitance and/or separate power supply.

4: Not sure, to be honest. I suppose you have to leave user-land and write your own kernel module in order to get best possible performance. I know more about hardware design than the internal workings of RPi and linux.

  Are you sure? yes | no

Vedant Gupta wrote 07/14/2017 at 03:48 point

Hello,  I am currently trying to make the Raspberry Pi work with the DWM1000 as well. Here is what I have so far

I am able to successfully send messages from a Raspberry Pi to Arduino via these radio chips but I have been stuck for days trying to achieve the same thing the other way around.  The Pi is not able to receive anything from the Arduino for some reason, I am performing the same exact steps on the Raspberry Pi as with the Arduino.

Have you had similar observations?  If yes, were you able to figure out a solution?

Thank you very much, any help would be greatly appreciated!

  Are you sure? yes | no

jaskhodja wrote 11/09/2015 at 18:05 point

Hi Göran, Could you please tell me how long will it take to a tag to make two way ranging with single Anchor ? If there are two tags how can they share channel?

Thank you

  Are you sure? yes | no

Göran Nordahl wrote 11/09/2015 at 21:52 point

It all depends on range vs power consumption. Use short preamble and 6.8 Mbps to get low power consumption and highest possible update rate, to the cost of shorter range. We use 110 kbps with long preamble to get long range. >10 Hz update rate with four tags is then no problem. I think individual measurement can be performed at 50 Hz using our settings. Look at the DW1000 data sheet for more info.

Two or more tags can use the same channel if you make sure that they never/seldom talk at the same time. We had some problems with crosstalk (, but that disappeared after introducing strict time alternation.

My colleague Niklas adds: For your application it could be an option to use one fixed tag and two mobile anchors (also anchors outputs range data). Then you do not need to worry about collisions at all.

Hope this answers your questions without creating too many new ones.

  Are you sure? yes | no

mickael.viot wrote 09/30/2015 at 15:55 point

Hi, This is Mickael from Decawave. Just wanted to clarify. All the datasheets as well as many application notes are available on our website in the downloads section. The app notes go from high level view of location systems, to the specificities of UWB down to very detailed documents about our technology and how to implement it. Only thing required is to login. Regarding the SW, our point to point SW source code is available for free as well, the only one that requires to buy a kit is the Real Time Location System SW source code. 

Thank you Loligo team for your brilliant job! 

  Are you sure? yes | no

jaskhodja wrote 09/25/2015 at 08:35 point

How do you track multiple tags at the same time? How do you do ranging? 

Like one at a time or simultaneously?

Thank you.

  Are you sure? yes | no

Göran Nordahl wrote 09/25/2015 at 14:35 point

As you can read here we had problems with crosstalk in the beginning:

Letting them talk one at the time solved the problem.

  Are you sure? yes | no

Chris wrote 09/25/2015 at 05:42 point

Is the price 2000 SEK? That's $240 for one unit? Seems sky high. 

  Are you sure? yes | no

Göran Nordahl wrote 09/25/2015 at 14:39 point

The current price for LPS Mini is 2000 SEK including VAT (1600 SEK ex VAT) if you just buy one unit. This is due to limited supply and the fact that we have built our current boards all by hand. The price will drop when we let a factory do the assembly. Read more at the bottom of this page:

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 09/19/2015 at 04:41 point

VERY cool project!  But... oh how I wish that people would just leave the ancient ATMega328P and 5V behind already!  No cool modern parts work at 5V any more, NONE.  Everything is 3.3V, has been for a long time.  And there are literally thousands of better micros out there that cost less, why keep trying to make everything work on this ancient piece of technology?

  Are you sure? yes | no

Göran Nordahl wrote 09/25/2015 at 14:42 point

In this case using ATmega328P was a quick way making it Arduino compatible. Next board is based on a Cortex M4F.

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 09/25/2015 at 15:07 point

Great, glad to hear it!

No need for OSHW to be stuck in the past. :)

  Are you sure? yes | no

Xavier Seignard wrote 09/15/2015 at 08:23 point

Is there any github repo of the source code?

  Are you sure? yes | no

Göran Nordahl wrote 09/15/2015 at 08:32 point

Not yet. The code needs to be a bit tidied up first. Currently the source code is only sent together with our boards. It is based on the example code from Decawave, but rewritten and simplified to fit into a 8-bit CPU (e.g. no floating point math).

  Are you sure? yes | no

Xavier Seignard wrote 09/15/2015 at 08:54 point

Ok! Hope to see the code soon :) I also use UWB in the field of arts, see there

  Are you sure? yes | no

Xavier Seignard wrote 09/14/2015 at 11:52 point

Nice project! I'm working with the same DECAWAVE chip right now, and seeing an open source solution is a very good news! I would love to get involved!

  Are you sure? yes | no

Göran Nordahl wrote 09/14/2015 at 13:05 point

Fun that also you are working with DWM1000! Or are you maybe doing it more from scratch using DW1000?

  Are you sure? yes | no

Xavier Seignard wrote 09/14/2015 at 13:46 point

I'm using this solution: it is based on DWM1000 and ST Launchpad board. The detection is pretty accurate and the latency is around 100ms. 

It was a great frustration when I saw nothing has already been done in open source around UWB.

But it seems times are changing!

  Are you sure? yes | no

Lahorde wrote 08/25/2015 at 15:16 point

Nice work...
Another solution for UWB transceiver could be be spoon chip integrated  in this this module that includes a STM32f072 :

  Are you sure? yes | no

Joao Ribeiro wrote 08/17/2015 at 13:21 point

Hmmm, that's a very inappropriate reply, like when you ask your gf if everything is alright and she says, yes "everything" is "ok" and you realise you'd better RUN!!!

Do not tease me with a "might" huh! Either do or do not, there is no try! (Yoda) heheheh

  Are you sure? yes | no

Göran Nordahl wrote 08/17/2015 at 13:49 point

Got a bit confused at first, but then I connected this reply with your earlier post :-)

The board I am currently working on got a different set of features, e.g. TCXO, 2.4 GHz radio, etc. Depending on my customers interest there will also be solder pads for a GPS module.

  Are you sure? yes | no

Antti Lukats wrote 08/16/2015 at 20:25 point

Hi what about licensing? it seems all DWM docuements are under NDA only? Or am I mistaken?

  Are you sure? yes | no

Göran Nordahl wrote 08/17/2015 at 05:46 point

Luckily you are mistaken, but I did a double check with Decawave last night to be extra sure. You need to buy a devkit to get access to their source code. That's about it.

  Are you sure? yes | no

Antti Lukats wrote 08/17/2015 at 05:54 point

ok that was not sure, there are NO PUBLIC DATASHEETS :( so it was not clear.

  Are you sure? yes | no

Göran Nordahl wrote 08/17/2015 at 06:38 point

Once you have registred (hmm... not sure, you might need a code that comes with the devkit to do that) you will get access to data sheets and good support.

  Are you sure? yes | no

Joao Ribeiro wrote 08/15/2015 at 20:53 point

Nice work.

Why not add GPS to a few so the system can get position locks on a couple locations using two devices on areas with coverage, and then use those locations for relative calculations to deduce the remaining base stations real latitude and longitude as best as possible.

This would make possible to integrate this with GPS maps, creating a seamless solution for outdoor/indoor position detection, which is very nice :)

  Are you sure? yes | no

Göran Nordahl wrote 08/17/2015 at 06:41 point

Who knows, there might come such a board later on :-) You will notice

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates