 Hello, my name is Max Nicotra, Technical Marketing in the America region for Teseo modules. Today I'm giving a refresher and update on ST GENESIS module family, Teseo Live 3, for the industrial T-positioning applications. I will introduce the ST Teseo big three family of GENESIS positioning modules and some of their many features that make ChemoGrip fit for mobility applications. After that, my colleague, Mike Slate, will provide an overview of our Teseo that reckoning draw-drawn solutions. In the last banal list, Bas Mamo, CEO of NavMedic, will present their Teseo Live 3F-based immobility solution and performance. Before getting into the Live 3 module details, I want to give an overview of the Teseo 3 chip set, architectural features. Given that the Teseo 3 chip set is the heart of Live 3 and Big 3 modules. So what is the Teseo? The Teseo is a GENESIS chip set family that leverages simultaneous multi-constellations to provide workplace GENESIS receiver performance for the numerous location-aware applications and it is automated rate certified. The Teseo 3 is a SOC, single-banded one multi-constellation that integrates considerable hardware functionality, as you can see in this chip block diagram. Starting from upper right, going counterclockwise, satellite signals come into the green block, which is the RF interface, which down converts the GPS satellites, 1.5 gigahertz signals to IF, four megahertz, which ADC samples and converts to three bits signal and magnitude data with AGC, automatic gain control. This data is sent to the white block or baseband DSP colorador engine, which does an early late type of correlation on the baseband signal and magnitude data to perform low-level acquisition and tracking. This correlation result and decoded navigation data are passed to the R9 core for position computation and uses the 256K young chip graph. Let's dive into the Live3 module family overview. So, the Teseo Live3 GENESIS module family is available in two flowers, the Teseo Live3F and the Teseo Live3R. The Teseo Live3F and the Teseo Live3R modules embed the Teseo3, which supports simultaneous of three constellations, GPS and Galileo, and neither Glonas or Baidu. They also support SBAS. The Teseo Live3F and the Teseo Live3R are the first members of the Teseo Live module family, enabling faster time to market with the same great performance and many features of the Teseo chip set. The Teseo Live3F is our best in class multi-concelation GENESIS module with outstanding accuracy for IoT ecosystems, good tracking, flip management application, and et cetera. The Teseo Live3F and the Teseo Live3R are intended only for industrial, consumer, and IoT applications. In the center is the module silhouette of, so sorry, in the center is this module silhouette. On the left is the list of the key features on the right to corresponding benefits. The multi-concelation with increased availability, redundancy, improves the tracking in a certain environment is often the case in urban or foliar areas and improves the special distribution of visible satellites, resulting in improved dilution of precision or DOP is beneficial to have a best-in-class accuracy. There are several versatile low-power modes allow tellering and GENESIS usage to application-specific needs and power budgets, assist the GENESIS to reduce the time to first fix, pre-load the functions, geofencing of the meter, data logging are useful basic functions for certain IoT applications. For example, people input trackers, fleet trackers, and insurance trackers. Pre-certified RF modules, Live3 modules are compliant with several RF certifications to reduce the sign risks, costs, and time. And Live3F executes firmware auto flash, which has two big benefits. The first, it enables firmware configuration changes to modify and expand the end product's capability. And second, it enables firmware upgrades throughout the product's lifecycle to improve performance and extend product longevity. Obviously, Live3R does not support all flash-based features. So both the Live3F and Live3R are a tiny, mid-less chip carrier or LCC 18-pin package. The module has three supply voltage lines, VCC, VCCIO, and VBAT at 3.3 volt, and the image below stated shows the Live3F architecture. In the center is the Live3F chip. Upper left, 26 megahertz DC oscillator for fast time to first fix. 32 kilohertz RTC for maintaining accurate time. And upper right, 16 megabit embedded flash for software execution and data storage. Reset and wake up inputs from host, PPS output to host, and UART, I2C, slave communication interfaces to host. Live3R has the same architecture Live3F by the flash. The modules allow to get a very simple design with a minimal BOM. So filter is optional, but recommended for the sign with collocated communication ICs. And the LNA is optional, but recommended for passive antenna designs. And the Live3F hardware user manual, which is available on st.com, provides complete information to support your design. Here are the evaluation boards. The XNUCLEO is ideal for STM22-based prototyping with a comfortable NMEA message output and command input over UART or I2C slave communication interfaces. It is available only for Live3F. EBB Live3F and EBB Live3R allow a complete evaluation, including power consumption measurement. All these evaluation boards are audible on st.com and through distribution. This is a free Windows PC-based GUI tool that is extremely powerful and easy to use. It is possible view, record, and playback NMEA messages, also for debugging, view graphics such as position, sky view, view and character noise ratio, send commands, and upgrade and configure the firmware. Let's dive now into the new GNSS positioning module family for mobility applications. The ZeoBig3D GNSS module family is available in two flowers, the ZeoBig3DA automotive grade for automotive market, and the ZeoBig3D industrial grade for aftermarket. The ZeoBig3DA and the ZeoBig3D are the first two members of the ZeoBig module family. They enable faster time to market with the same great performance and many features of the Zeo. Three chipset and support SD draw, that reckoning algorithm which arguments the position accuracy and availability, especially when the GNSS signal is degraded by environmental conditions such as tunnels, urban canyons, indoor parking, and multi-level highways. Draw, exploit the integrated SD6 axis IMU, 3D accelerometer and 3D gyroscope, which is automotive grade certified in Big 3DA. Here are the same considerations made previously applied. Both modules support simultaneous three constellations, GPS and Galileo in either GLONUS or Baidu, and support also the SBUS, satellite-based augmentation system. Several versatile low-power mods, low-tailoring GNSS usage to application-specific needs of our budgets, assist the GNSS to reduce time to first fix, and both modules execute a lot of flash which has the same two big benefits, enables firmware configuration changes to modify and extend the end product's capabilities. And second, it enables the firmware upgrades throughout the product life cycle to improve and extend product longevity. Big modules are tiny, shielded, little less, chip carrier or LCC, 24-pin package. The modules have three supply voltages line, BCC and BCCIO at 3.3 volt, and we bet in the range of 2.1 to 4.3 volt. At the C oscillator for fast to time first fix and RTC oscillator for maintaining accurate time for hot start fixes are integrated in the modules. A flash memory for software execution and data storage is embedded into the CO3 chip set. On the right lies the big three pinout. Pin 15 up to the left and pin 4 lower right are the signals relating to the automator. Pin 4 forward vehicle direction input pin, binary value forward or backward, and polarity is selectable. And pin 15, the will tick, automator input pin. Big 3D modules make prototyping quick and easy with a minimal BOM. On the left you find the automator signals, which are optional but preferred if available. The automator data can be provided over wire by pin 4 and pin 15 or yours. In this case the external host fits the big 3DA with will tick data via NMEA, NMEA input message. So fielded optional but recommended for the sign we call located communication ICs and LNA optional but recommended for placebo antenna designs. The big three hardware and software user manuals on our website provide complete information to support your design. A GNSS function is used to avoid cold start after four hours and warm start between two and four hours by predicting the position does reducing time to first fix from around 30 seconds down to one to four seconds. These are three, there are three modes. Self-train with computation being done on chip in a background task. The prediction works well if I'm not moving under different satellites say 61 miles or 100 km away. The predicted is a lighter computational load to the around 12 kilobyte packet download via TCP IP. It works everywhere, download the family's data typically every 14 days. And the last one, real time, works everywhere, download the family's data typically every two hours if I'm not moving more than 61 miles or 100 km away since the last download. Low power mods. Adapting, it works in raw mode. And if the GNSS module is tracking several satellites being part of different constellations, it could be possible that the contribution of some of them to the accurate position measurement is marginal or nonexistent. In this situation, the system can decide to turn off a constellation of constellations. The estimated horizontal position error, EHB, is the discriminant parameter. Cycle, it works in raw mode. The position is calculated each second. DRF and baseband are turned off to the 70% of the run time. Pre-order fix, it works in GPS only. After the preprogrammed time, the lift 3F wakes up, calculates the fix and moves back to standby. The last one is the fix on demand. It is connected to an external event. For example, let's imagine a system which is supposed to be still an accelerometer connected to an external host detects a movement and the host wakes up the lift 3 to recalculate the fix. The module operates using the last save configuration. Here are some draw-and-dram related features. I will let Mike to introduce them during the second part of this presentation. There are three standard pre-order functions. Detalogging, this memory is part of the flash. Integrated to the ZO3 chip set, which is hosted in the VIC-3 module. Geofencing, there are up to eight configurable circles and odometer. It provides infinite travel distance, but is not a step counting. The EBB VIC-3DA evaluation board is a complete standalone evaluation platform for the ZO3DA and the ZO3D that reckon genesis module for features evaluation and also for power consumption measurement. To find out more about the ZO genesis module families, live3 and VIC-3, as well as get access to permanent technical documentation in the ZO suite, go to www.steve.com slash genesis modules. VIC-3D modules will be available in Q1 2021. I recommend you join us in the SD genesis community to share ideas and ask questions. Thanks for your time. Now I want to hand over to Mike, who will provide an overview of our debt-recony draw-dram solution. Thanks again. Bye. Thank you, Max. Hello, everybody. I am Mike Slade, and I am the technical marketing leading for the ST Tessio positioning solutions. And I'm really excited to be able to share more details about the Tessio debt-recony solution that Max mentioned, which is a core feature of those Tessio VIC modules that we are offering soon to the market, making them really the best fit for all types of mobility and tracking applications. And I actually want to mention that this presentation was primarily generated by my esteemed colleague, Nicola Paola, who leads the navigation systems development team out of our Agrate Italy office. So I'm going to start it off with a poll question. The first one is, do your products currently leverage GNSS technology? So I'd love to hear from you since the polls and the Q&A at the end are really our only tools to make this a dialogue instead of a monologue. So I would greatly appreciate it if you could each take a few seconds to answer the poll. So debt-recony, commonly referred to simply as DR, perpetuates position, velocity, and attitude when GNSS is either, one, not available, for example, when in tunnels or parking garages or other areas where there's a complete loss of satellite signal, or two, when GNSS is available but not accurate due to reflective or widely obscured environments such as in big cities with a lot of tall buildings, as you can see in this picture, which we uneffectually refer to as an urban canyon. And that's because really all the medium and low-angle signals have trouble directly reaching the street where the user typically is located. So shown in this diagram on the left, you see its draw, our debt-recony automotive way, which is a Coleman filter-based algorithm that estimates position, velocity, and attitude using various sensor inputs. So from the top of that left diagram, you'll see, going clockwise, those sensors are HIRO for YAR heading, an odometer for distance traveled, an accelerometer for pitch, temperature, and most important, the GNSS, which is considered an input because it is used to calibrate the draw algorithm. So we run the draw algorithm directly on our Tessio core so it is closely coupled with our GNSS Coleman filter algorithm. Then shown in the diagram on the right, you see drum or debt-recony unplugged mode is also a Coleman filter-based algorithm that estimates position, attitude, and velocity. Using the same sensor inputs, as you can see, except one's missing. In the upper right, it's the odometer, hence the namesake unplugged, as it does not require a direct connection to the vehicle. And it is really more a fit for aftermarket applications and various mobility-specific applications. So drum, in turn, computes distance traveled from linear displacement of the accelerometer. The key to draw and drum performance is the 6-axis IMU. We highly recommend the STASM330LHH for best automotive performance or it's industrial equivalent for that, which is the ISM330LHH or the LSM6DSR. So Tessio drum, I want to talk about a little bit more its specific advantages or value add features for navigation, telematics, and mobility. Automatic temperature compensation, or ATC, is what actively compensates for thermal effects to the IMU, guaranteeing long-term accuracy. Automatic free mount, or AFM, autonomously determines and accounts for PCB installation of the end product, guaranteeing consistent optimal performance independent of how it's mounted in the vehicle. MATMAGE feedback, or MMFB, allows map data from the end application to be fed back to draw and drum to still improve navigation accuracy more so. Low-level interface, or LLI, enables the solution's position, velocity, and attitude, and time, in fact, that output at a rate of up to 20 hertz, and also an IMU data output at a rate of up to 100 hertz, all with minimum latency and jitter for absolute accuracy. And lastly, not shown here, but also available is sensor over UR. So it is offered for architectures where the IMU is not directly connected to Tessio. Hence the sensor data is gathered by an external processor and sent to Tessio via UR. Drum performs the same computation and with minimal latency and jitter from that host data, ideally less than 10% of its delay or transmission time, an accurate PVT can be provided. So this flow diagram is a high-level overview of the drum fusion filter. It depicts system inputs such as raw GNSS measurement data in the upper left and raw IMU data in the lower right. And the Tessio firmware keeps both the GNSS and IMU data perfectly synchronized. In other words, we have a sensor input data handling and buffering routine that's optimized for minimal latency and jitter as I mentioned before. And what it does is it enables very quick an accurate sensor calibration and ultimately an optimal fuse navigation output. On the right, you can see a list of output states and position velocity and attitude are the primary output states which represent the dynamic system of interest, which in this case is a vehicle. And then there's some secondary output states that consist of IMU calibration parameters, IMU installation angles and others not shown. Essentially, the system estimate is driven by the sensor's input in the loop to the right of that diagram in the middle you see. And that from 20 to up to 100 hertz depending on the actual system, meaning to be modeled and how dynamic that system is, meaning vehicles such as cars are not as highly dynamic as drones. So this system estimate is concurrently being corrected by the left loop, which is the one hertz GNSS fixes. And that's of course when, like I said, it's available since GNSS is not always available like in a tunnel or it's constructed in a city. So the green boxes you see in this diagram represent the system equation matrices and K represents the common game matrices which optimally controls the current observations as they vary within specified tolerances or what we call covariance limits. The established, well-established common theory dictates that the modeling of both sensor measurement noise in the R matrix and process noise in the Q matrix also be taken into account. So the crux of the matter is this sensor fusion or common has to be calibrated, has to be calibrated quickly and maintain an accurate state estimate. So from very first power up of an ECU for example in a brand new car, the new is mounted however the design dictated and the gravity vector is quickly determined while the vehicle's static and position on the road. So the orientation of the three axises of both the gyro and accelerometer become known with respect to gravity in that vehicle supporting now the subsequent DR computations and after some initial driving course or rough initial calibrations refined or the gyro by executing some turns which is what helps us dial in the yaw parameters and for the accelerometer by executing some straight driving and dialing in that accurate linear displacement calculation of distance traveled. So good GNSS is actually required as a reference during this calibration period but then these common states like I mentioned are periodically recorded to MDM and that power down so that at subsequent power cycles of the vehicle over the life of the vehicle the states are extracted from MDM and at every power up and the solution retains that fine or very accurate calibration that's already learned for this vehicle over the life of the vehicle maintaining that the DR performance doesn't vary from time to time. It is consistent and continually improving. So thank you for answering our first poll question the responses to do your products currently leveraged GNSS technology makes me think oops I apologize makes me think several are just learning about it so that's good to know I'll tailor kind of my discussion that some for sure use it or in development or future plans so it's good to see it's good to see this is quite an even distribution so of course you know for those of you are in development or future plans by all means you'd be glad to discuss in after this with whom your requirements and see how we can help you achieve the addition of GNSS to your solution. Here is the second and last poll question of the day and it is if your product does require GNSS what are your three requirements and again I'd love to hear from you since this question gets more to the heart of what your application needs from GNSS. So just wanted to talk a little bit about the IMU that I mentioned before the ASM 330 LHH which is a 6-axis IMU and it's been designed from the ground up for automotive applications and it is actually qualified for AEC Q100 with an extended temperature range to positive 105 degrees C. The navigation accuracy is directly proportional to sensor noise and temperature dependence so that all invariance commonly known method is used to characterize low frequency noise which impacts this navigation accuracy over longer integration periods and in the lower left you see the stability features listed that show a value of 3 degrees per hour for bias instability or EI and 0.21 degrees per root hour for angle of random walker ARW which if you're not sure how those compare they are best in class and in fact ST is the only manufacturer to publish BI and ARW in our data sheet which reaffirms our confidence in being best in class and as I mentioned for industrial designs by all means the ISM 330 LHH is a lower cost equivalent solution. So I just wanted now to share a little more real data and this is the first of a couple slides. This is a snapshot of a recent competitive performance comparison in two very different environments. First off on the left is the open sky environment or highways which typically weight GNSS in the fusion solution more heavily because the GNSS signal is so good in highway and open sky that many signals are available there's few reflections and as you can see the circular error probable or CEP 50% error is approximately 1.4 meters in this environment. On the right, the second environment is urban canyon which typically weights DR more heavily due to GNSS, multi path reflections and obsecration it has to de-weight some of those questionable signals as I previously mentioned. So the CEP 50% position error is greater in this case it's about two times or approximately two meters two times the open sky that is due to lower availability of line of sight signals and generally weaker signals of GNSS. So our ST drum metrics in the blue bars versus competitors metrics in the pink bars indicates that drum has slightly better performance at CEP 50 and significantly better performance when we evaluate one and two centimeters. This is a snapshot of heavy foliage performance and I apologize it's a bit of an eye chart but I'll try to direct you. So the upper left plot shows several long sections of heavy foliage where the blue track depicts GNSS only positions and the light yellow between those blue depicts the three sections where GNSS signals are greatly degraded. And so if you look closely at each foliage exit and to do that you need to note that the vehicle is traveling from right to left in that picture and so from outage one to outage two to outage three as you can see the blue GNSS only position shows slightly higher position error for those first few sections after essentially it comes out of the heavy foliage or comes out of those yellow sections because once it exits and starts to see those GNSS signals more clearly again of course they're quickly being reacquired but in that brief period there is a little bit of I should say there's increased error but now looking at the lower right plot which is the same drive test but it's showing the red which is actually our fused position with GNSS and drum and again moving right to left of course you know through outages one two and three the white depicts the drum only track and in this case we've switched to pretty much drum only like a tunnel because the heavy foliage is that thick and again looking closely at each exit of those one two three foliage outage sections you do not see that greatly reduced position error because the drum has provided continuous tracking in the presence of weak GNSS signals so there's really not this gross error at the exit that demands reacquisition but instead the drum keeps a continuous position all through the route so this is an example how drum maintains that continuous lower tracking in all environments as designed to and needs to so this slide is a chart that shows position accuracy of the drum filter during a complete GNSS outage again it's based off a real field data using the ASM M330 LHH 6-axis IMU with actually our Tessio 3 solution and is the result of 30 test runs to ensure that there is statistical significance and the position error is simply expressed as a percent of a distance traveled in a tunnel the leftmost group of four bars shows one sigma errors for respective outage distances the middle group is 2 sigma and the rightmost is 3 sigma and as you would expect the percent error increases for 2 and 3 sigma but only linearly not exponentially confirming that the ASM 330 LHH is excellent performance with drum is bared out or out and so also you can see that the 4 kilometer tunnel performance is in some cases equivalent to or better than the half a kilometer which confirms that we still have this excellent bias instability and angle of random walk regardless of the duration because different tunnels have different durations so you really want to have as good short and long term duration performances you can get so we are looking at the response now to our second poll question and it looks like that cost as always cost is very important for sure and then power consumption so which makes sense because what we've seen as we DevCon appeals to more mass market or IOT applications so a lot of IOT applications are very power concern with power and cost for sure and so looks like performance and size are relatively comparable to so that's and that's what I would expect a fairly even balance a lot of times cost and power consumption are slightly bigger so again thank you for taking the time that helps us to know how to tailor our solutions so that they're the best fit for your application so again please do reach out to us after this presentation if you'd like to discuss your GNSS requirements in greater detail so thank you all very much for taking the time to learn more about our Tessio GNSS plus draw and drum solutions and of course the live and Vic modules that Max shared and to find out still more about the Tessio chipsets modules draw and drum or any of our products in that family line feel free to visit the ST.com slash GNSS modules landing page or ST.com slash GPS landing page so next I would like to introduce Boaz Mamo the CEO of Navmatic who is a valued ST partner who is developing solutions for micro mobility with various ST products such as Tessio thanks again bye thank you Mike and thank you Max for for giving us all this information I personally learned a lot from what you guys presented I present my name is Boaz and the CEO of Navmatic and we are focusing on high accuracy position for micro mobility now if we're talking about micro mobility what is micro mobility micro mobility is the solution of small vehicles that are usually replacing car rides in the distance of up to five miles it's what we all see in our cities like scooters and bikes, at usual electrics and from what we seeing today the micro mobility is a growing market it's a market that predicted to be like 500 billion dollars in almost 10 years and even today we see a huge growth in the sales in the interest of the audience in micro mobility and as much of this industry is booming and growing with the growth there is also coming a lot of problems and the problems that those companies are facing especially the shared mobility companies is around accuracy of position because first of all they have a lot of problems with regulators a lot of cities like Dallas and Copenhagen banned micro mobility from their cities because they don't like the people throwing it and parking it anywhere and that's caused a lot of problems to the micro mobility operators. The second thing is for operation personally and myself I started a company because I was trying to find a scooter and save time by getting my destination in a faster way and found out that I'm wasting more time looking for the scooter rather than to ride on it but when I worked on the solution I realized that operators also have a lot of problems to operate the scooters because they need to charge it every night and their employees need to find the scooters just can't find them because sometimes they can be a block away from where they can see it on the app with a more accurate position those operators find ways to create smart geofencing have a better rider experience and also been able to operate better their operation what we've pneumatic did we look for develop a solution that utilized existing sensors and new sensors that similar to the drum basically using IMU, speed data and GNSS data to generate a better location. Now the question is why do you need special dead rock name for micro mobility and the reason is that we found out that the physics of a scooter or a bike is very very different than a car a car you cannot lift and switch to 180 degrees on the other side turns are different there is so many different aspects between cars and micro mobility and therefore they needed to have a better DR dedicated for micro mobility the other thing that we added is our solution data we took correction service and we added it into the GNSS measurements in order to create a better measurements when we came into the solution we realized we need to have first of all some kind of evi kit that we want to test our solution and also shared with our potential customers and on the high level the things that we realized we need to have on the evi kit we added an MCU that obviously because the aiming for IoT needs to have as much of high performance as possible with low power we need a GNSS module that is going to be cheap but will enable us to have access to road measurements in order to implement the corrections we needed six axis IMU to make sure we had the accelerometer but also the gyroscope which is super important when you're having a scooter and we need to have a connector that can enable us to have a wheel tick or speed data to integrate in our solution and not least we need to have an internet connection in order to send our data to the cloud but also enable us to send our corrections to the device and when we looked into the existing solution we found in the ST kind of ecosystem the perfect match to all what we needed we used the nuclear STM32F7 to be our MCU we took the live3 GNSS module to enable us to have access to road data measurements and we took the six axis IMU from ST when we found out it's like the best performance for price that we can find out there especially for IoT applications this is how our EV kit looks like in real life and we found out that we also was really easy to build a custom shield that enabled us to change different modules that we need one of them for example we're looking now into the test CO5 also for higher performances in some of our customers and it makes it much easier to work and to change modules on existing shield this is our test scooter as you can see the red box on the bottom this is the system and above it obviously it's our grant truth system that enable us to understand the performances of our system and on the right you can see results from San Francisco over here you want we wouldn't be able to have a good grant truth system but we use the map in order to like see the performances of our system one interesting thing is that a lot of DR for example automotive using map matching is very fast that for scooters you can really use map matching because scooters can ride against traffic small alleys on sidewalks not necessarily riding on the road which makes it more challenging for the DR if you use map matching so we're not using map matching in this slide you can see results of our test in a standing scooter in a good really good up in sky performances based on the live 3 F receiver here you can see our test result in Santa Cruz which is pretty much light I would say over in environment and on the image you can see that the difference between the white line which is the genesis with our corrections and DR versus the yellow line which is what the genesis by itself performing and here you can see a test that we run in San Jose and you can see how the grant truth is the white line the green one is our solution and the red one is how genesis performing and you can see the big difference between how genesis performing versus our solution compared to that thank you very much for your time and for listening and I want to take this opportunity also to thank the SE team for the support to build that we needed a lot of support for the team and Mike and the team really help us to do that and if you have any questions we'll be happy to answer on them now thank you