Welcome to installment number thirty-five of the Design Challenge Project Summary series here at Element14. For those of you who are new to my content, in this series I chose a single Design Challenge project from current or past challenges, and write a short summary of the project to date. I am selective about which projects I summarize, as I want to highlight quality content. Unfortunately, projects that stall out, or get abandoned are not chosen for these summaries. Some project creators like to keep their own project summary going, and this series is not meant to overshadow those post, but to highlight each project from an outsider's perspective.
Who hasn’t wished that they had a bicycle that could double as a personal assistant? I know that I have, and that is exactly what Gurinder hoped to create with project SbSr. Noticing the uptrend in the smart wearables IoT market over the last few years, he knew that the time was right to finally create his own smart bike, or at least a DIY, IoT connected, bike PC that was able to do come cool stuff. In the project’s introduction post, Gurinder laid out the plans to create the ultimate smart device that could attach to a bicycle. Unfortunately a temporary but untimely move off station set the project back by a few weeks and gave Gurinder a serious disadvantage starting out. Nonetheless he laid out a solid plan of action, and we would just have to wait until the next update to find out what progress has been made.
It was nearly three weeks before Gurinder was able to ease our anticipation with his second update. With so much time already lost, he knew that it was important to get the ball rolling pretty quickly, so he began working on designing the GUI that the bike’s system would display, and to make the design process as easy as possible he decided to use a program called Nextion. “It is a Display solution which makes GUI designing and Interfacing with the Main Embedded System so much easier, plus It Offloads the display subsystem to a co processor,” he wrote.
The project’s third update was delayed as well coming almost a month after the previous update. The delay was again due to Gurinder being moved to a remote station with very little access to the outside world. Upon his return he was pleased to find that the challenger kit had arrived, but the joy of receiving new hardware to play with quickly subsided when he realized that the shipping box had been damaged in transit which in turn caused some damage to the hardware contained within. Fortunately the damage was minor, and amounted to little more than a few bent header pins.
Update number four arrived just a day later and Gurinder explained the methods he could use to measure the bike’s speed, distance traveled, and other metrics that could be calculated by counting the revolutions of the bicycles tires. He settled on using a Hall Effect Sensor, and after some tinkering around with an Arduino Yun, he had the sensor feeding back data that he could use to calculate the various metrics mentioned above. “When I came across This beautiful device called as Hall effect Sensor , My eyes sparkled while going through the data sheet and my gut said; This is it,” he wrote.
At first glance you would think that the project’s fifth update was being written from a sandbox, but then you scroll down a little and realize that this update is so jam-packed with awesomeness, that you forget all about the sand! And by Awesomeness, I mean DIY PCB etching! That’s right, Gurinder brought out the ferric chloride, copper clad board, and a sharpie, and the end result were very functional hall effect sensor breakout boards. I really like the barebones DIY method of hand drawing the circuit traces with the sharpie marker over using a toner transfer method or something similar, and was really glad to see it being done this way.
With the hall effect sensor breakout now made, Gurinder used his sixth update to highlight how he will use interrupts in the code which will allow him to begin some preliminary testing. Update number seven focused on interfacing the Nextion display with the STM32 development board and the issues that arose. Thankfully Gruinder was able to overcome the issues and move forward.
Update eight was a short one with the focus being on the lithium-ion battery that would be used to power the bicycle computer when in use, and how Gurinder plans on keeping the battery charged. Continuing work on the power system, update number nine was all about reducing the power consumption of the system to provide better battery life. Knowing that the LEDs that illuminate LCD screens account for the largest power draw, Gurinder focused on designing a system that would let him reduce screen brightness when the display is not being used, and would quickly go to full brightness once the screen had been double tapped on.
The project’s tenth update was another short one with a brief update on the hall effect sensor, and how well it was performing. Gurinder provided a demonstration video showing the sensor in action, so check out the full post to watch the video. Update eleven was also short, with a demonstration video of the serial interface in action, as well as a lot of the source code for readers to look over. Another very short post came with update twelve with Gurinder quickly describing how he will be mounting the system to the bicycle.
Tragedy struck between updates twelve and thirteen when Gurinder had a crash while out testing the SbSr system. Thankfully he walked away with only some minor injuries, but unfortunately the same was not true about the project. The STNucleo board and sensors survived, but the LCD screen did not. This, along with his injuries, and another pending remote station assignment forced Gurinder to abandon the project. He did post an additional two project updates detailing the sensor subsystem and the BLE subsystem so please check them out if you are interested.
That is going to wrap up my project summary coverage of project SbSr. I always lead off these summaries by telling you that I do not write summaries of projects that are unfinished or abandoned, but this one was different. Gurinder put a lot of time and work into his system, and was unable to finish the project due to an accident during its testing phase. I felt it was important to write about this project to highlight the fact that things outside of our control do happen from time to time, and I do not want anyone to feel discouraged from making things after having a failure due to an unavoidable accident. I fell that for all intents and purposes Gurinder had planned on finishing the project, and I felt that he had created a decent project. I hope he has fully recovered from his injuries by now, and would like to thank him for participating in the IoT On Wheels Design Challenge. That is going to wrap things up for me, so tune in later this week for another Design Challenge Project Summary here at Element14. Until then, Hack The World, and Make Awesome!