All right. Thank you, everybody, for stopping by to my talk. This is more of a higher level talk compared to the previous talk that Johan gave. This is basically an overview of an experience that I had with a client implementing a custom USB device controller driver using Zephyr RTOS. So a little bit about myself. First, I'm an embedded software consultant based out of New York City in the USA. The design work that I've been doing, I've been working professionally for about 15 years as an embedded software engineer, started my consulting company in 2019. So we're looking at about four and a half years now where I've been doing consulting work. Most of the design work that I've been involved in have run a number of different verticals, including medical devices, scientific instruments, which have mainly been in the agricultural space, of course, automotive, defense, and because of where I am geographically, a lot of consumer electronics for a lot of startups. And of course, my expertise and experience more recently has been with RTOS based systems, of course, including Zephyr, and for most of the time that I've been working professionally, a lot of it has been in the metalinics, mainly using Yachter project based BSPs to deliver software solutions for a lot of my clients. And on the application side, I've been working mainly with QT based applications. So essentially just running the entire gamut of the embedded software stack, right? From RTOS based to Linux, kernel space based applications, and also now a lot of user-based applications as well. You can check out my social media, LinkedIn and Twitter. I hope to get connection requests and follows from all of you. It'd be great to just connect with everybody and just have a conversation online. And I've also been recently getting involved in trainings and workshops. You can sign up for my newsletter, where in addition to getting a schedule of when these workshops and training courses occur, you can also just get insight into some of the things that I learned throughout the course of my project work. And of course, you can reach out to me via email and check out my website. So for today, this is a simple agenda about what we're going to talk about. First, we're gonna talk about the project, just look at the system architecture of what we're trying to do or what we were trying to do, the problem statement. And then we're just gonna go over a really brief USB primer. It's just meant to kind of level set of the conversation and understand what we're aiming to achieve. Then we're gonna talk about the initial approach that we went through in implementing this custom driver. Some of the challenges that we faced, how we debug those issues initially, what steps we took, what tools we used, what the final resolution was, which in my opinion, wasn't the greatest resolution, but we had to do what we had to do to get a solution out to do it to a customer. And then next step, right? If I were to redo this project, which I'm actually working on right now, again, like on my own time, what sorts of steps that I could have taken to improve the final solution and what are actually the next steps that I'm working on? And then we're going to conclude with questions. So just quickly going over the project and what it entailed. So the client came to me and said, oh, we have an encluster based, it's a Xilinx based board, encluster makes basically production ready, so they're not development boards, they're actually boards that you can place into final solutions that are ready to be delivered and they're production ready. They had initially UART console, and so essentially it's a zinc based platform that has a hard ARM core and they just have a UART console to it and ethernet essentially. So those were the main initial peripherals that they had on their system. And this is a diagram of the system architecture. So we have on the bottom right an ARM hard block. And so this originally had the implementation that they wanted in terms of all the peripherals on their MCU based solution on the FPGA. And their goal, their target really, they created a custom, well not a custom, but they used an off the shelf risk five core and they wanted to create an application around that for their own kind of project. And they used Xilinx IP to serve as the USB controller for device site. And again, this is a hard block and they had a UART controller as well. Again, Xilinx IP, another hard block that both of those essentially tied to the risk five core and the ARM core was not only just used for debugging, but also did the risk five core implementation by just accessing the risk five memory but it also had access to the memory registers and the registers of the other hard blocks. So we could poke and peek at the different registers on the USB controller and also on the UART controller just to see, hey, what was the state as we started to implement and test out the implementation? What were the actual registers that the hardware reported for debugging purposes? So like I said, the existing system, it was based on an Enclostra based Xilinx FPGA board. It had a hard ARM core, it had UART console, Ethernet and then the big component for this project was the USB CDC. And so their existing system from a software perspective used free ARTOS. So they had two versions of the implementation. One is the final, which again was a simple implementation where they just had a few peripherals that they had on their system. They had a Blinky basically just an LED that just demonstrated that the system was up and running. The USB CDC, which was the focus of this project, a network interface and then for the debugging implementation, again like I said, they not only had access to the risk five memory but also registers access to the other hard blocks as well as USB, UART, et cetera. And of course they had a network interface to basically, so essentially the way that you loaded going back to here, the way you loaded, let's say like in this case we were targeting the risk five core for the Zephyr implementation is the host side would actually communicate over Ethernet to the ARM core and then you would basically transfer the Zephyr binary to the ARM core. You would issue a command and then the Zephyr binary would essentially write the Zephyr application into the risk five core. And so that's why we needed an Ethernet or a network interface on the free ARTOS implementation on the ARM side. So what, and if you looked at, if you sat into Anna's talk, this keynote this morning, kind of the problem with a lot of ARTOS, especially free ARTOS now is that it's not cohesive unlike Zephyr, which you have a USB stack available for you. So they needed to actually incorporate a separate stack. They used tiny USB for this. It has USB host and device capability and it's targeted for embedded systems. So it's memory safe. There is no dynamic allocations. It's thread safe so that all the interrupts are deferred so essentially you would have to implement some sort of task to go through and address the interrupts that have occurred. And it's cross platform and open source. So this is kind of similar. So a lot of the USB stacks, this is similar to how Zephyr, like we saw in Johann's talk, how it's implemented in Zephyr. At the top you have the application. So this is a custom implementation that we have. We have the underlying stack itself, which is essentially the middle region. And then on the bottom we have the actual MCU port. So essentially in their implementation and their free ARCTOS implementation on the ARM itself, they just implemented the two ends. They had a task at the top and then essentially they just implemented the interface to the Xilinx hard block at the bottom. And that's it. That's all they really needed to do. So just really quickly just looking at how tiny USB implements a lot of the abstractions for not only OS but MCUs. Basically you just have to enable, and this is important because we'll see later on like what we ended up doing to get this work with Zephyr, which is a poor decision on my part, but we'll get to that later. So essentially all you need to do is just set a macro to enable certain the OS abstraction that you want. So if you want to use free ARTOS, you just specify the appropriate macro and then you have all of the essential free ARTOS primitives that you want to implement in tiny USB. Similarly, so here we can see basically this OSL MS2 tick and if we enable free ARTOS, that's essentially what we have. We just have a really thin layer to the underlying free ARTOS implementation of like counting a tick essentially. And then they also have support for different MCUs. So again, leveraging a lot of the underlying microcontroller based on implementations of like leveraging some of the synchronization primitives, you can enable using hardware based primitives by specifying the appropriate MCU type that you want to use, right? And so for Xilinx, what they did is they just added another option for Xilinx in tiny USB and then all they did was just okay, set that configuration option. They had a thin layer to implement some of the Xilinx primitives and that was that. So basically in the tiny USB implementation, just added another directory for Xilinx and that's all that was really needed. And then from the other side at the application layer, just implementing the appropriate tasking to address the device interrupts as well as some of the mechanisms for the CDC implementation. So right, so not only did we have to enable it for Xilinx, but also just set it for FreeRTOS to set the config option for FreeRTOS, enable the CDC class and then implement the relevant application code to manage the CDC interface as well as the device interface. So like I said, just to summarize the application, what it ended up being is just like an echo application. Basically you just have a task that's receiving data over the USB CDC and then just echoing it back, transmitting back over USB. And then for the MCU port on the bottom side, on the low level, you have the interrupt handlers and then for initialization purposes, writing the appropriate registers in the controller itself in response to tiny USB function calls. So the problem that they came to me was, hey, we wanna take this, we have a RISC-5 core, we wanna actually use the Zephyr stack now to work, to basically do, to interface with the Xilinx USB device controller and we wanna do the same thing that we have where we have a CDC controller and we just wanna be able to echo data and then ultimately not only just echo, but we wanted to take measurements about in terms of performance. So later on there was like an IPERF application that was built to start exercising because we have to do, for higher speed, for bigger packets, we need to do DMA instead of like asynchronous function calls. So just use the DMA controller also in Xilinx and they wanted to be able to validate well, how well is the DMA controller working? Is that all configured properly or are there some bottlenecks that we're not aware of? But this is going to focus more on the asynchronous, just sending a single character, really small USB packet, making sure that that's functional. So again, that was the goal of the project, it says, okay, we wanna implement this now using Zephyr. So just a real quick, before we dive into what we did, just a quick overview about how USB works. So it all starts with when you plug in your device into, let's say your PC, your computer, right? The host side determines that, oh, like something is connected, right? There's some device out there, so it starts interrogating the device. It identifies essentially the type of device that it is and the services that the device provides. And then once it identifies, okay, what sort of device it is, from a hardware perspective, what sort of services, quote, unquote, from a USB perspective that the device offers, it loads the appropriate host driver on its end, right? So there are a couple of USB transfer modes. There's a control and we'll get into some of these later. There's the interrupt, there's a bulk, and then there's the isochronous. So how does that integration process occur? So it's essentially the basis of a USB transaction. There's a token packet, so there are a number of different packets that make up a USB transaction. There's the token packet, which essentially just has a header and it tells the device, okay, there's more stuff that's about to be, that coming your way, so get ready to start processing it. There's the data packet, which can be optional, but it does contain the actual payload itself. And then finally, there's the status packet, either that's reported by the device or the host to tell it that, oh, that what you asked me to do was successful or sometimes I'm not ready yet, can you come back to me later, which is essentially a knack, and then let me continue to process that data and then come back to me later. And then there's also mechanisms in terms of a status packet for error correction. So when I first got started with USB, this was a mindset that I needed to have, because everything starts with the host. It's a bit weird because when you're coming from other protocols, it's something to get used to and you have to basically form your mindset when you're looking at a lot of the USB traffic, like understanding what's going on, you have to realize that the host controls everything, so there's nothing that the device can do unless the host actually requests it. And so this is also reflected from the language as well. Some of the language that we see in USB, it's derived from this mentality that, oh, everything is from the host perspective, so just keep that in mind. So just looking quickly at a USB packet, so there's some standard fields that exist in the USB packet, there's the sync, which is again in almost all communication schemes, there's something that exists, whether it's wired or wireless, there's something that exists to tell the other party that, hey, this is a specific region in the packet, use this for synchronization, or I'm telling you, I wanna start communicating now. There's a packet ID, which instructs the side about what type of packet it is. There's the address, again, because USB is a bus protocol, you need to tell the device that, hey, the host needs to tell the device that this is meant for you, and then there's the endpoint, which we'll get into later. And then the token packet, again, understanding the language right in means that the host wishes to read data from the device, so it's from the device to the host, and then the out, you know, that terminology and out token packet is essentially the host wants to write data to the device, or send it, or transmit data. Right, it's all transmission, so transmit and receive is hard to kind of conceptualize, but you know, I think understanding these specific terminologies is helpful. And then finally, setup basically just is an instruction from the host that advice telling it that it wants to start an actual transaction. And like I said, there's the final portion of any USB transaction is the handshake, so an act is an indication that, oh, that the packet has been received, I'm working on it, right, and you know, everything is good to go. An act is usually like, hey, you asked me to do something earlier, I'm still working on it, like you asked me for a response, right?  And then a stall is usually when something horribly has gone wrong, hey, host, you need to step in and like, you know, do something to basically correct what I'm doing. So kind of a quick graphic about what the general gist of a USB transaction looks like. So we have the token packet that comes in, the actual data packet, which can be optional or have a payload in it. And then finally, we have the handshake packet that contains the result of the actual transaction. So going into briefly about endpoints. So again, if you look at the arrow, it's essentially, you know, everything is initiated by the host. So the host is always asking for something or telling the device something. So let's say, you know, initially, the device gets an interrupt that says, from the host, it says, oh, I have data on endpoint one out. So the device recognizes that interrupt, right? It goes to the appropriate buffer that corresponds to that endpoint and for not only that endpoint, but also that direction for that endpoint. And then once it's done processing, it just dumps data into, let's say the endpoint one in buffer, right? So now that data is sitting there. There's no mechanism for the device to let the host know that, oh, you can read now. It's whenever the host decides to read later, oh, you know, I wanna see if data is now in endpoint one in, it's right there, right? For the host to retrieve. There's no mechanism for the device to let the host know that, yes, I'm done. Here you go. Right, another important thing to keep in mind is that optional payload in the data packet is a corresponds to what's a zero length packet, right? So let's say the host sends out an out token to send data to the EP1 out buffer, as we saw in the previous slide. Now the next time, so it wrote, the host wants the device to do something. The host to see if the device is ready or has parsed the instruction and has a result ready, the host sends an in token to check whether, like, okay, did the device receive it okay, right? And it uses the zero length data packet because there is no information, right, that the host wants to sell the device. It says, hey, is everything okay? Did you get it? And then, so it uses that zero length packet. And then so if the device has successfully received the packet and is on its way to processing that information, it just responds with an act. And then so, like, and we continue the device, process the data in the endpoint one out. So if, let's say there was an error, the device didn't expect the data in the packet, it just responds with an act. Otherwise, if everything looked okay in terms of processing that data, the device just responds with an act. Similarly, let's say on the other side, right, the host wants to know, okay, enough time has passed by, do you have data for me to actually read? So it sends an in token to read data from the EP1 in buffer. And so afterwards it sends the out token to see if the device is ready for the next transaction. And again, it uses the zero length data packet to see if the device is actually done and ready for the next transaction. So just the zero length data packets that I learned during the course of this project was, these are pretty important. There's some mechanism, there's some way to, by the host side, to enforce flow control in USB, essentially. And so just some more kind of information about USBs that all devices must support endpoint zero. And so it receives, a device receives all control and status requests during enumeration using endpoint zero. And it also, this endpoint allows the host to identify the functionality that's provided by the device and to determine which other endpoints are available as well. So the enumeration process from my experience with this project has been that the device descriptor request is one of the first things that happens. And so you have the setup token, the data in that setup token is the device descriptor request. And then you have the next process, which is the host actually requesting, determining which are the descriptors that the device actually returns back with. And then the out token is really just, okay, are you ready? I have all the descriptors of the endpoints and services that you support. Are you ready for the next transaction? So the initial approach, leveraging, again, what Johann was talked about was we implemented the device callbacks, again, from the lower side and also using the low level API and the high level API. So just going about, I just started implementing some of these callbacks. And from the host side, we used Windows for just the CDC host driver, plugged in the device, right? And then we checked her term to see if the character is being echoed. And before that, we essentially just use the Windows device manager to say, okay, does it show up as a compor, right? And we use print case essential functionality like just to determine whether all the callbacks and functions are being exercised, whether they're being called. But we're not done, right? So of course, when we try this, as we all know, it fails the first time, right? We plug it in, right? And Windows just fails on the initial enumeration process. It doesn't know what, which during the device descriptor request, it just fails immediately. So what do we do, right? There's so much further that we can get with troubleshooting using print case. So we needed a way to independently track the USB transactions. So we used this tool. It's a pretty powerful tool. It can basically just plugs in line with your USB device and then you can essentially just store all the USB traffic that's going from the host to the device and see, okay, where are things going wrong? And so this is really just a capture of the traffic that's going back and forth with our device and with the Windows host. And there's a lot of information here initially. And so you tend to see a pattern. So what we ended up seeing was that, and do I get here? Yeah, and then the other, I'll talk into what we actually saw with those captors. And the other thing we actually ended up using was Xilinx's internal logic analyzer. And this was, this is like a hardcore like FPGA diagnostic tool because the print case aren't helpful. The tool isn't helpful because you don't know exactly what's going on, like why the actual FPGA is responding the way it is. And so what this tool allows you to do is with really fine time precision, see the actual signals in the FPGA to help you determine, okay, from the controller side, like what's going on? And the other thing that we use is also the ARM core, right? Like I said, the ARM core is actually hooked up to the USB controller. So what we would do is we would actually, you know, this is really naive and barbaric way of doing debugging, but we would like have like infinite while loops at different stages of the USB initialization stack in Zephyr and then just start poking like, okay, from the ARM side, okay, we have access to the USB controller register space. Let's just see what it thinks should be happening. And so that was another mechanism that we used to troubleshoot like what's going on. And what we learned was through these kind of troubleshooting steps was we didn't actually set up the Xilinx controller properly. It was always sending out Nax. And so what would happen is the host would try, try, try, try to do the initial device descriptor request. And because we didn't configure the controller property, we would always be sending Nax out. And so eventually, right, the host has to give up eventually, can't keep requesting forever. And so we realized like, okay, we actually didn't configure the registers correctly. Like I said, we also used the ARM core to basically peak and poke the controller registers to actually determine what the actual registers were. So what did we do, right? Fortunately, we were running out of time, right? This was like, you know, we tried, couldn't figure out what was going on, like how to appropriately implement our driver. So we did, we, you know, we took a really hard pill, it was really hard pill to swallow when we just decided to port tiny USB to Zephyr, right? We completely sidestepped to Zephyr Sack. It's a pretty, I'm ashamed of this implementation. Like I really, I literally had a bag over my head for a couple of days. My daughter was asking me, you know, why am I so sad? And so we created, and it wasn't too bad, right? We created a new OS port for Zephyr, right? Again, we used essentially, that was why I kind of pointed out all these different layers for the different RTOSes. So we created an OSAL for Zephyr. We just implemented a lot of the primitives that tiny USB uses for, you know, tasking, for delaying, for getting ticks, just using the Zephyr primitives. And we, at the application level, we just created two Zephyr threads. One is to manage the actual device transaction, right? The controller from the FPGA side to set everything up, okay, when interrupts are fired to defer those interrupts and then, okay, come back around and start acting on those interrupts. And the other thread that we created was just a simple application thread to just echo the CDC, right? So we have CDC data coming in and then transmit that back over to, on the Xilin side and just write it to the register. And when we did that, it worked, right? So ultimately, that implementation, we were able to get a COM port for open windows. We were able to echo back characters from our Xilin implementation back to the Windows host and everything seemed fine. But, and so we're done. For now, yes. And so some of the next steps were, this was one of the first times that I got involved in Zephyr. So this was about a year, year and a half ago. So I was naive at the time. It's like, oh, the documentation says just implement this, right? Just implement these callbacks. I didn't, thinking back, I should have taken more opportunity and I think I've grown in the past year where I've learned to actually dig through the code and actually get a sense of what's going on. And so at that time I was afraid. So just some lesson like, it's just code, right?  Nothing's gonna blow up hopefully, right? It's just not gonna work, right? So going back, I probably would have actually read more code to understand how the USB stack works and what the best way was to actually incorporate the underlying Xilin's device driver into the USB stack. I mean, one of the other requirements that they had was to have like a cake config and a device tree options and that worked, like I'm happy I did that, right? Like I had a little, like when you ran the cake config GUI like the Xilin's driver showed up, which was nice. But happy customer, right? They actually just reached out to me before I hopped on a plane to come here and say, hey, are you free like mid July to like work on another Zephyr project? So like, okay, great. So it's not kind of the perfect solution but in the commercial world you learn at some point like, hey, whatever works and makes your client happy. Like, you know, you gotta do that in time but I'm not done yet, right? So sure, client is happy but I'm not entirely happy so there were two options, right? One is to port tiny USB to Zephyr properly, right? I just implemented just hacked in just the Ocell there but that's pointless because we already have a pretty neat USB device stack, why not leverage it? So what my next step is to actually incorporate the Xilin's USB driver into the Zephyr stack and properly, right? And sure, I'm not gonna use the RISC-5 core because I don't have access to it but I can just use the ARM core, right? Just create like a simple implementation using the hard ARM core on a Zinc and then just incorporate the device controller and then just implement my driver the proper way and just, you know, I have a Beagle analyzer. I can just use that to, again, go through the same verification process and I don't have access to it in cluster but I do have plenty of Zinc development boards and so that's kind of like my next step. Any questions? Nope, cool. Well, I'm gonna take like one last pitch everybody. Yeah, cool, thank you.


Good morning, I'm Elgin Farewell, the CEO of Terranet. Like my colleagues, I'm here to talk about a story of transformation in land registration services. I think you're going to hear that none of them were achieved overnight, and none of them were achieved without challenges. Those challenges can be political, policy, operational, technical, and if you've ever worked in land registry, they certainly can be emotional. I know while I'm here to talk about the Terranet experience, in many ways it's more about the Ontario land registry staff that had the vision, the commitment, and the leadership to make it all happen. In Ontario, meaningful transformation took almost a decade, and while both the model that delivered the transformation as well as the services have continued to evolve over that decade, since that decade, I'm here today to share the early Terranet story by setting the impetus for change, the strategy, and the structure to address that need, and then talk a bit about some of the high level lessons and results that have been realized. So a decade might sound like a long time, but not so much if you think of it in the context of a land registry service that had not changed in close to 200 years. Settlement, European settlement, started in the 1600s in Ontario, but it wasn't until 1795 that provincial statutes were introduced to establish land registry and land rights. At the time, land was administered under a deed system, which was a variation board from the British. But in the late 1800s, Ontario adopted the new Australian torrent system for first grants to property. Now while enhancing property rights for some, this also created disparity that would last for another 100 years for those that were still under the registry deed system. And over those 100 years, Ontario itself went through profound change and growth. Initially, 80% of the Ontario population was rural in nature and was spread across a geographic area four times the size of Great Britain. So over 60 county-based registry offices were established to service and administer property rights in the province, each of which had their own interpretation of the provincial Registry and Land Titles Act given the geographic distribution. During the 1900s, Ontario became Canada's economic engine, population more than quadrupled, and the demographic profile shifted to 85% urban. Development of land became intense, and like most jurisdictions, development fueled surveys, transfers, and mortgages, which in the registry were all fueled paper, paper, and more paper. This in turn put significant pressure on the urban registry offices in particular. In Ontario, a real estate transaction does not close until you actually register the transfer in the registry office in other words, you don't get the keys to your house if you don't get registered on your Friday afternoon by your lawyer. In the 1980s, with population and the economy booming, the land registry system was not coping. It was bursting at the seams with paper staff and customers. We're actually setting up tents in parking lots where offices could extend their services and lawyers and conveyancers would come to register. The register was consistently missing the legislative timeline to complete transactions, and in a period of intense development, this created exposure for the province, for properties managed under the Torrin system, and was potentially putting confidence in the land registry system itself at risk, and confidence and trust is fundamental to land registry services. By the 1980s, roughly 50% of the provinces, the properties in the provinces were titles, and 50% were still under the deed system. Registry staff and legal community had to maintain two legislative administrative systems and workflows, as well as the expertise that would be prescribed by each to manage them. Again, it also meant that those who held interest in land did not have equal rights and protections provided by the province. Some were able to rely on a provincial guarantee while others simply had to rely on their lawyer. So in the mid-1980s, the government concluded that the inconsistency of rights, the increasing cost of the service, and the decreasing level of service was creating too much risk for what would be considered a critical piece of economic and social infrastructure. So to address this, the government created a vision for real property administration in Ontario that planned to leverage the newly emerging information technology capabilities, and that vision was to afford all property interest holders the same protections and benefits by proactively converting the deed's properties to a qualified title under the torrent system. Create an electronic, parcelized ownership database for every title in the province with an integrated electronic workflow to enhance the efficiency of the registry staff, and coincidentally create a digital, parcelized geospatial map fabric as an index to the property records as well as an expandable database for property attributes that could help inform public policy. Finally, it included a long-term vision to automate the real property document creation and registration process. Today some know this as e-convancing. Now many jurisdictions in the 80s were building title databases, and so that was not that unique. What I think was unique was at the time, the decision to convert millions of properties, property records from a deed system to a title system as a starting place, and then envisioning a world where the end-to-end land transaction would be paperless, automated, and conducted remotely was unique. And while it was understood that the effort to attain this long-term vision was large, the government did not know at the time that the scope of magnitude of the vision would become much greater than anticipated, and this in turn would drive the need to be innovative in the way in which that vision was achieved. Initially, the land registry took on attaining the vision on themselves and started by designing and developing the Polaris Land Titles Database and Operating System. They did this successfully, and then to support the records conversion, they developed enabling legislation and procedures to streamline the process to search a deed's property, parcelize it, automate it, and certify it under the Torrin system. Unfortunately, after a series of pilots, the Land Titles team concluded that the cost, difficulty, and resourcing to convert and map almost four million titles and the complexity of the desired enabling information technology, as well as the related investment to enable all of that exceeded the government's capacity. So to their credit, to the government's credit, they did not reduce the scope of the vision they were trying to achieve. They looked for an alternative model to achieve the vision and concluded that a new trend in public-private partnerships for hard government infrastructure might actually be adopted to a soft infrastructure environment. So government saw an opportunity for a private sector partner to bring capital, discipline, competency, and capacity in surveying, technology, and process optimization, as well as bring a commercial lens to customer service and to market newly created data. Again, to their credit, they anticipated that unlocked value in land registry would be released and that this could be captured and retained by government, but also shared with a private sector partner to accelerate that vision. And in 1991, Terranet was created as a 50-50 partnership between the Ontario government and a private sector consortium. Terranet and the private sector were expected to bring the capacity and the expertise to accelerate the conversion of titles, drive IT solutions, innovation, allow government to guide and government project outcomes, but still remain focused on processing day-to-day land registry records and then provide the capital and be motivated through an economic model that maximized and accelerated the benefits of automation to land registry and its customers. It took two tries to get the right consortium, but ultimately the private sector owners were comprised of survey firms, legal firms, technology firms, all backed by capital that committed the required funds up front to the province. However, a clear vision, capital and experience was not a guarantee for long-term partnership success, so why did it ultimately work? Clear accountability of roles, rights and decision making and the adherence to these trickled down from a joint Terranet board that had equal representation from government and the private sector partner as well as independent expert members. Terranet would be accountable to meet performance and production criteria that included quotas, timelines and quality for records conversion. The government continued to own the data and certify the title using the system that Terranet would deliver. Terranet on the other hand, designed, operated and owned the system within which the data resides. This created a symbiotic reliance on one another and a shared and aligned view of the customer. And while Terranet retained fee revenue, government retained fee control. So fees were predictable and grew at a pace that was known to the customer base. Once critical mass was reached on the number of parcels automated, Terranet could commercialize the data but government had the approval rights from a privacy perspective and a market perspective. Terranet was only compensated by retaining statutory fees on automated properties. In the early stages, this motivated the company to focus on simpler land titles, properties generally found in high turnover urban areas. Government also set performance standards for system availability, the rate at which properties needed to be converted and data integrity for those properties, all of which had significant penalties attached. So you had the combination of revenue upside and performance downside, which motivated Terranet to successfully standardize the processes and the performance standards for title certification staff in a unionized environment. And having been around the world, I can tell you that's not easily done in the complex world of land registry. Well, this model drove revenue to Terranet which would be used to fund more conversion. It also allowed government to process records more quickly due to the advantages of automation. Given the long-term nature of the arrangement, it was important that government was not fettered in making policy or legislative changes that might need to be reflected in the systems that Terranet was maintaining on their behalf. So a comprehensive governance structure was established and evolved to monitor contractual performance and customer service. But more importantly, it was a commitment to dedicate the right talent and decision makers that facilitated the ability for the regulator and Terranet to work collaboratively on advancing the vision, being innovative and adapting to new needs within the marketplace and within government and to jointly engage stakeholders and customers. And I'll talk about that in a minute. A fund was established and collaboratively annual planning process. So Terranet would fund on an annual basis any changes government wanted to the system, which could be driven from an operational perspective or by legislative changes. And I'd say the most significant of which was a move towards reducing property fraud and enabling that with systems checks in the 90s. I believe another key to the success of Terranet was that from the beginning it was not singularly private sector and composition. Terranet was seated with government board members and the voluntary transfer of government land title staff over to the company when it first started. And to this day, we continue to recruit and retain a contingent of both government and more specifically land titles capabilities and DNA in the organization. Having government representation at the board level in the first decade and hiring former deputy ministers or sorry, deputy registrars not only allowed the company the credibility to engage and contribute to the transformation and a true partnership with government and stakeholders, but it also allows us to understand and work within a government context. It appreciates that public interest is a business interest. A conversion project that was supposed to take roughly 10 years took 17. But that was because the number of properties and the complexity of those properties were underestimated in the 90s or the 80s. Despite this, by 1999, critical mass was reached and with the busiest and largest counties automated and converted to land titles. So in 1995, anticipating success, Terranet and the province set about to introduce the electronic remote registration system. But the vision did not just see the automation of land registry processes as they existed today. It also envisioned the reform of land registry practices, policies and legislation by moving away from the submission of evidence to the use of legal statements. Government collaborated with Terranet, but they actually led the engagement of stakeholders in this endeavor. And it became a joint effort with the Law Society of Upper Canada and the Bar Association to reform and change the real property practices with a goal to rely more heavily on the legal profession, reduce property risk and create a more efficient marketplace. The legal community was engaged and allowed to influence, which ultimately turned them into champions of change when we rolled out the system. We worked closely with the government to design and develop the system based on the reformed and more efficient workflows supported by auto certification, or sorry, auto signatures, online collaboration between parties, including the registry office, the auto population of title details from that automated database into the electronic documents so that you knew that that information that was being submitted could be checked and would be right, as well as being able to be automatically abstracted and registered without human intervention. Prior to the launch, Terranet and the government together delivered a comprehensive change management program to ensure that the community was aware, supported and trained, and as mentioned, the legal community was in support led by the Law Society. And in 1999, TerraView became the world's first digital land registration system and it immediately transformed the practice. After the successful launch of TerraView and with the records conversion, nearly complete, the government sold its 50% interest in Terranet in 1993 to its partners. Three years later, we went public through an IPO. Government participated and saw a return on investment. I'll talk about that in a second. In 2008, Terranet was taken private by a pension fund and is now operating the electronic land registry system for the province under a 50 year concession arrangement and has strict performance and customer service requirements including a contractual commitment to maintain the registry in a modern state. But above all else, the governance regime that provides clear accountabilities promotes joint strategy and the funding and collaboration to achieve it remains the underpinning of success. The province's original equity investment in Terranet was that actual Polaris system that they built in the 80s which was valued at less than $30 million. But since the province divested and over the life of its relationship with Terranet, its return on investment received in hard proceeds so these are checks being cut will exceed $4 billion. 6.4 million parcels have been automated and converted and 99% of documents are created and registered electronically today. This is in an environment where the properties, the number of properties of double transactions have increased by 25% and the land registry in Ontario, its foot prints been reduced by 75% through the use of public kiosks. While land registry staff have been reduced from anywhere between 1,200 to 1,400 depending on the time of year, they've been reduced down to 200 and but the backlogs have gone from 20 days down to one day. And finally customer service satisfaction is in the top decile and we measure that regularly. This has been a journey, not a journey, this has not been a journey without its challenges. They always are but a commitment to the vision and the innovative business model has transformed land registration in Ontario. Terranet continues to deliver e-convancing property risk and realtor solutions across Canada and has recently entered into a 30 year concession with the province of Manitoba where once again we are faced with paper, paper and more paper and we'll start that transformational journey once again. Thank you.


It's a nice trip to here. It means the same thing so positively about Ireland's role and I wish goodness they could get all their colleagues out and start preaching that message. Because we've been listening to so many people, be moaning and wailing and you know the end is now. So Minister, thank you. Thank you very much. Former Deputy and Minister. Thanks. And the front here, the very front. My name is Roland McGrath and I work in the AIB. I'm wondering if you think, I felt during the last few years that the Irish people attempt to blame the Europeans not for the things that were kind of for a lot of mistakes we made ourselves. I'm wondering, do you think that the Europeans feel that we've actually changed their mindset and that we now are going to take more ownership of the problems that we've created ourselves? Yeah, as well as, first of all, we always take that, the rest of the world when they're having their breakfast in the morning, across the table to their wives and say like, I wonder how they're getting on in Ireland. So most of the time the Europeans don't even think of it. We don't cross their minds at all, you know. And it's like this, I watch Bloomberg a lot. And very often international investors and international commentators and politicians form a view of a country by the one line that goes across on the table. The Greek set the default, sets it for the day. That's the image you carry with you. So we have to be super careful in what we say because it's the era of the soundbite. And the image of Ireland is established by a series of soundbites frequently on the financial channels. So to be aware of that, you can work into that then to reset the reputation of Ireland by making sure that all the messages that are going out internationally are very positive. So we're sticking to our program and we're going to stick to it. We're going to pay our way, we're not going to default to restructure. We have a growing economy again, we want to grow our way out of this. We've restructured the banks and they don't require extra capital. They're beginning to access money and the wholesale market again. Their deposits are coming in again. You know, it's job, it's export-led growth and we're balancing payment services. And they're only one-liners, you know, but they all get into the financial markets and that's what creates the different image of Ireland. And we keep putting out the positive message. And positivity leads to positivity, you know, because the missing ingredient in domestic market in Ireland at the minute is confidence. Like if we could build confidence in the domestic economy in Ireland, we'd be in a very good place very, very quickly. So that's what I'd say. Thank you very much, Roman, for that question. Now, the next question or comment. And we're locked in the play, over in the room. Thanks, Chairman. Minister, the financial markets are challenging democracy across the world in that moment in Europe. And I suppose it's true to say that we're having a demographic crisis. What steps do you think are needed to counter this challenge from the financial markets? Well, the firewall to speak about it is a defence mechanism in Europe. But this issue is a much wider issue. You see it hitting the states as well as Europe, and it's not going away. And as a democracy and as a democratic people, we have to summon and ask ourselves, how is it going to be addressed going forward? Thank you, Lord. Yeah, it's a difficult question to answer. Because certainly the markets have a very strong influence at present. And they're forcing decisions on democratically elected leaders, which they might not take. But rather than seeing some kind of, you know, conspiracy at work, I think we should look at the situation in countries as well. The markets are kind of mindless, you know? There's nobody kind of directing it. And the markets react. They're like some kind of force that reacts to the data that they have. And if they see risk, they'll avoid it. And if they see profit, they'll go towards it. I mean, Richie Ryan used to say when he was in my job, that there's nothing as funky as money. And it'll run from risk always, you know? And a lot of what's happening in the market and what the kind of conflict between democratic leadership and the market is, I think leadership not acknowledging that the manner in which they've organized their countries is not correct and adjustments have to be made. Now, the adjustments are being made very rapidly. I mean, you see the situation in Ireland with the banking disaster and the government, previous government moved very quickly to put in a new governor and a new regulator and to again merge the roles of regulator and central bank in the one institution with a proper hierarchy and have staffed it up very much. So regulatory regimes are very, very important, you know? The markets were right about the recapitalization of the banks. I mean, the stress testing that was done across Europe in June was very good stress testing. But the line was drawn too low in terms of tier one capital ratios. And it was ridiculous to think that the markets would. Ireland had a very good insight into this because we recapitalized the 10.5% to quarter one capital in the end of July on American-based stress tests. And the Europeans were saying everything will be grand if we recapitalize it 5%, 5.5%.  I argued the case with them in Europe. I said, you're wrong, you'll become back to this again. And they're recapitalizing now at quarter one and 9% plus market to market. So what I'm really saying is that the markets need to be controlled by more regulation, but we have to acknowledge as well that very often the markets are really reacting to flaws in the economies of individual democratic states. And it's up to the democratic leadership to fix those flaws and not just to blame the markets. Okay. I think that, in my side, I think that's Dennis Cobb, am I right? I think while we were meeting and by the minister was talking we had a quite an initial development in Athens, as I read in my back for you. Captain Rail has offered to resign. And there are talks and allegedly the report is going on to form a national government and the Prime Minister being spoken about is the chairman of the Greek National, the Greek Central Bank. I think this might mean we probably don't have to face a Greek referendum of course you don't know everything in speculation but it looks as if Greece might be sorting itself out. Thank you Dennis. That's very good news, Dennis. And I mean it confirms democracies will sock themselves out. There are similar talks in Italy, I don't know how it's going to play out but the best rumours from Italy are that they're going to form a national government principally of technocrats and former commissioner Mario Monti is going to be asked to be the Prime Minister. But I mean, I can vouch for that. That might be just high class rumour that I'm getting on the phone. Okay. Great last question. I think I'm going to park Murphy here. Yes? Party member Jinskir. Minister, one of the things that has been talked about in connection with this crisis is that eventually we will have a proposal to amend the treaties in the direction of greater integration. What do you think is the idea of this and what is the Irish view on it? Thank you Parth. The position is that President Van Rompuy has been asked to look at what needs to be done to implement the agreements made at the heads meeting recently and to report back to the heads meeting in December on the possibility of whether treaty change would be required or not among other things. Now, one of the things in the communique which concerned us was that the authorities in Europe want to enshrine the stability and growth pact in law and they wanted to do it by way of referendum where you would have a constitutional break on having deficits that are too high. They pulled back from that. So in the communique they said a legal break preferably in the constitution. So we'll be able to meet that recommendation under law. The Irish position on referendum is that we don't think we'd get it through at present but if it was a referendum which enhanced our position and it wasn't a simplistic change in the treaty then we'd look at it and we'd examine it. We can't be seen to kind of stand in the way of progress across Europe but I don't think from what I hear there'll be any proposal to change the treaty for four or five years. The Lisbon Treaty from the first time it became a matter of conversation took seven years before it was actually implemented. So there's a long lead-in time in Europe for a lot of these things. So I don't think we're going to be faced with an immediate treaty change but the Irish government position is we think that 95% of what needs to be done can be done within the present treaty framework but we're prepared to examine any proposal to change the treaty and we won't rule it out simplicit but we're putting down the marker that we'd have great difficulty in getting any European treaty through a referendum in Ireland at present.


Hi there, this video is not really like anything I've done before. It's not a video essay at all So I just want to let you know that right off the top What this video is is just kind of a bunch of cool visuals that I've been making over the past few weeks Basically what the story is is that I'm throwing a Halloween party and I thought it would be cool to have Cool surreal trippy visuals on screen for the duration of the party So, you know, I know a guy who's good at motion graphics. He's me. I am that guy So I decided to throw some together, but I didn't just want to hoard these graphics for myself You know, I get a lot of amazing compliments from people about my motion design and I thought all of you would appreciate these So I'm putting them all here, but I'm not just releasing them here I'm releasing this entire video into the public domain That means that you can use these visuals for absolutely anything you want You can take this video down tear it into pieces Reassemble it obviously that means that if you're throwing a Halloween party, you can throw some visuals up But I thought that these might have some other uses beyond that you know, I've talked to some musicians about having stuff on projection screens behind if you're a band and You want to use these for that that would be amazing. I would love to hear about that Let me know if you do anything like that in the comments. All of these are pretty close to perfect loops It's it's a little difficult to make things loop perfectly. So there's a couple glitches But you know, they all pretty much loop for around a minute You know, so you can you can feel free to take them apart Reassemble them however you want loop them in whatever order you want again I just want to release some cool stuff into the ether and Let you play around with it If you want an extended version Which is the version that I'm going to throw up for my party. You can go to the link in the description There's an unlisted link to an hour-long one where I've extended each of these loops into five iterations So the whole thing is like an hour and change. So that's a little more feasible But also, you know, if you want to just play this one on repeat, that's cool, too What I do ask is that if you're gonna do something with this I'd love it if you tossed a bit of support my way. There's a link to my coffee below Or you could sign up to Nebula if you signed up to Nebula You could watch these loops with no ads you could make them available for offline watching Which is really cool and it's also just you know, you get all kinds of other cool stuff You've seen my videos, you know Nebula ad reads the other thing that's going on is I've got prints now through imprint some of these loops I've Adapted into prints that you can frame on your wall if you want a piece of my art in your apartment or in your house I think that would be really cool. And there's some other art there, too This imprint thing is a real experiment for me. I want to do more of it I want to adapt some frames from my videos into art So, you know on that note if you've got any favorite frames from videos of mine Let me know in the comments and you know I might look into adapting those into prints that you can buy and I'm also just gonna keep creating more weird Original art that I'm posting on there and also let me know in the comments if you use this for something If you're a band you can take these clips turn them into visualizers for your songs Again public domain absolutely free of charge If you do that and you want to shout me out or you want to toss me a bit of money for that You know, I appreciate it But the entire idea is for this just to be an experiment in creating art and throwing it out there to See what people do with it and if you really like one of these things and you know, you're interested in Working with me to develop something based off it for I don't know Maybe a maybe a lyric video or you know a promo or something like that. I am I am open to Working with you I've worked with some bands before to make lyric videos It's something I really love. It's something that you know, that's something that I can't do for charity I need to actually be getting fair recompense for that But if you're interested, you know, if you like one of these and want me to adapt it into a custom lyric video for you and you're willing to pay fair price Please reach out. You can find my business email and and reach out. That's something that you know, I'm I'm open to Discussions on some of these clips are, you know, completely original just weird visual experiments Others are sort of adapted from videos that I've been doing before, you know, some polyphonic videos Some my Halloween short series that's been ongoing where I've just been doing spooky stuff I don't know. Really. They're all just meant to just be cool and beautiful So I hope you enjoy them. And yeah, if this is something that you find cool If this is something that you find useful, please let me know in the comments. I would love to hear about it I'd like to do more of this at some point. I love making little visual loops. Motion design is a great passion of mine So I think it would be cool if you if you guys Find some use for this the long version is completely silent so you can just mute it and throw it on with any sort of Backing music that you want throw on your favorite Halloween party playlist. Hey, let me know if you, you know Have any playlist that you think works well under this. I want this to be something experimental and communal I want to give you guys a gift of something to Watch or to play around with or you know, just to like just to put on when you spin your favorite record So yeah, thanks. Thanks for doing this again If you want to support me there's links to all sorts of different ways that you can lend your support to the channel in the description and Congratulations you you own this now This is this video and the extended version these clips are in the public domain So they are yours to mess around with however you like and I'm excited to see what you can come up with If you end up doing anything with them, please just let me know in the comments I would love to see what artwork you guys can come up with Okay, I'm gonna let this play out now. Enjoy the visuals and hey happy Halloween