In April of 2015 I found a Kickstarter called Bluz which offered a cloud-connected Bluetooth LE development kit that could be run off a coin cell battery for months or even years on end. The Bluz is very similar to a product called the Particle Photon released earlier last year and the Photon has quickly become one of my favorite development platforms for developing Maker projects. I figured that a Bluetooth LE dev kit would be a great addition to my maker tools.
After a bit of wait, it arrived on my doorstep and I figured that I would record an unboxing video and a simple test with the Bluz.
Since I pledged $49, I received what they call the Wearables Kit which included one Bluz dev kit, a Coin Cell Battery Shield and an Accelerometer shield.
The accelerometer shield that I received was not a custom Bluz created one, but actually a Sparkfun branded shield that I had already purchased on my own (an extra never hurt).
The coin cell battery shield is unique to the Bluz and allows it to be powered off a single coin cell battery. Included in this shield is an on/off switch that is surprisingly missing from the number of other battery shields that I’ve bought and tested.
The Bluz itself looks very similar to the Particle Photon and actually has the same footprint so that it can take advantage of the same shields as the Photon. It even piggybacks off the Particle’s online development tools and the same deployment pattern (aside from the need to be hooked to a gateway that I’ll talk more about later). One big difference in the immediate presentation of the Bluz is that it does not have a micro USB port for powering it. This is partly due to the fact that it can supposedly last longer periods of time on very little battery and its primary purpose is to not be continually connected to an outlet. The’ recommended method of powering it is to use the coin cell shield, or the VIN, or 3.3V pin
For my unboxing, I didn’t have a method of powering it through the Vin or 3.3V pin directly or a coin cell battery lying around, so I decided to use a Particle Shield Shield in order to breakout a DC Power connection (which ends up powering it through the Vin pin anyways).
The major thing to know about the Bluz is that it needs to be connected to a gateway or the Bluz iOS or Android apps in order to communicate to the cloud. While there are plans to open source the iOS and Android connection code, they haven’t been released yet and this is a pretty big limitation for anyone like myself that wants to use a direct communication line between Bluetooth devices and the Bluz. However, Bluz sells a gateway shield that can be attached to a Particle that allows up to 8 Bluz to connect to it and communicate to the cloud.
Also, I have yet to test out the claim that it can last months or years on a single coin cell battery, but will be using it future projects and will be testing this out. There is one difference in the code that supposedly helps the Bluz achieve this feat. The code inside the loop function contains a System.sleep call in the default sketch.
//this, and only this...
I expect the Bluz to be a worthwhile investment and can’t wait to see what kinds of projects I can build with this low powered Bluetooth LE dev platform. I love that they leveraged the Particle ecosystem and online development IDE as well.
Lately I’ve focused more of my efforts on Youtube videos for the side projects that I build. While I enjoy the process of writing blog entries, I also found that I enjoy the visual draw and documentation capabilities that Youtube allows me for the generation process of my side projects. Through the provided analytics I’ve been able to see that the videos I make generate higher engagement, but the value of written posts in providing engagement for text and programming related questions and solutions is undeniable.
The latest video I’ve posted to my Youtube channel is about the making of an LED mask. I have thought about the project in the past and this October I decided to build one using a Particle Photon as the controller. Due to the spacing of the Neopixel LEDs on the strip (60 LEDs per meter) I decided to interlace the strips with an offset.
For those that don’t know, Particle was previously called Spark and I had used their first product, the Core, in the past before the Photon was released. The Photon is evolution of the Core. While much of the platform has stayed the same (both the good and the “could improv), it remains one of my favorite hardware development boards due to its size and capabilities. I’m looking forward to the upcoming release of the Electron that I backed on Kickstarter.
While I was creating my first build and began to put my first working prototype together, I figured I would document my parts, their prices, and explain why I chose them. I’ve split up the BOM into two parts, the electric longboard components and the board components which are usable on their own for a normal longboard. I decided to go with a single motor design for my first build (it seems fairly trivial to add a second motor in the future) and so far it’s been handling pretty well on hills. The only downside is that sometimes if I lean all the way to the left, the right back wheel comes off the ground slightly and I lose the driving traction. For more info about the trade-offs, check out my previous post.
The way a typical electric longboard works is, you (the rider) use the transmitter to speed up or slow down. The transmitter interacts with a receiver that is hooked up to the ESC (Electronic Speed Controller) which interprets the signal and turns it into a motor signal. The ESC needs to be hooked up to the battery for power since the ESC is what drives the motor. The motor then turns a gear which is hooked up to a belt that will then turn another gear that is attached to your wheel. This is how your longboard will gain movement.
5065 designates the size of the motor and is a common size for electric longboards although they typically have a smaller shaft. 170kV designates the torque the motor can produce (the smaller the number the higher the torque, but the lesser it’s top speed).
$25 – Wiiceiver – (Not needed if you are using the VESC)
A way to control the input to the ESC coming from the wii nunchuck
I used this in the interim while I was waiting from my VESC to be made and shipped to me. With some configuration it turned out to work decently well. I was able to ride it on flat or a slight incline, but with less power and it would cut off if the motor started to draw too much power.
DIYElectricSkateboard sells an aluminum part for the motor pulley and I figured that since it’s the part coming off the motor shaft and is only connected by two set screws, it makes sense to get this part made of aluminum to handle the stress.
Originally based off a 9mm pulley model, I had to add bigger holes for stronger screws and a couple other changes. I will link to the design I put together for this part once I’ve tested it and made it fit reliably.
This works out well and is made of aluminum. This can be replaced with a cheaper non-adjustable mount, but I didn’t like the idea of welding on a mount to my longboard trucks and had not ability to do the welding.
Due to my choice of wheels, these had to be altered in order to fit them (I used a file to make a bit of room for the screws that hold the gear onto the wheel) If I were to do this again, I might try the Paris trucks since they are more symmetrical.
I originally saw the video above in May 2015 when The Void released the video and was given the spotlight by Virtual Reality enthusiasts. The ideas behind it reflect the future of virtual reality entertainment. Their goal is to make you feel like you are inside the virtual reality world. In order to accomplish this, they’ve integrated small elements into the landscape like heat, wind, water, texture, and movement to make it feel like you are experiencing what you see in the virtual world.
Virtual reality and augmented reality technologies are becoming more accessible and gaining popularity. A lot of companies like Oculus Rift, Microsoft HoloLens, HTC Vive, and Google Cardboard are investing in the space. While most companies are targeting home usage, it’s hard to feel truly immersed in a virtual world while sitting on your sofa or standing in your living room. The interactive environment with haptic feedback helps to truly forget where you are.
I just hope that the experiences of all Virtual Reality headsets live up to our imaginations.
One of the issues I’ve always had with mobile development is needing to scale images to support the multiple icon sizes and splash screen sizes. While customized icons and splash screens for each device is a valuable asset for any application, I’ve always viewed it as this tiring and monotonous task that needs to get done for mobile development.
ionic resources command. Now that I’ve been doing more mobile development with the Ionic framework and Cordova, I realized that they’ve got a plethora of tools to make mobile development easier.
In an Ionic project there is a “resources” folder that contains
splash.png along with android and ios folders. If you run
ionic resources from the command line within the Ionic project, it will automatically take the icon.png and splash.png and scale them or crop them to fit the appropriate sizes.
If you just want to regenerate the icons or splash pages only, use these commands:
I’ve always been interested in mobile application development and I learned Objective-C for iOS app development. However, as my web application development experience increased, I started to question the scalability of code for different mobile platforms (iOS, Android, and Windows). Developing separate applications for each platform with similar functionality but utilizing each platform’s separate SDKs and languages didn’t seem like the best method.
Because of this, I began to lose interest in native mobile development (Especially with the regular updates to the OS and slight changes that meant that I would have to keep updating the code for each new version) and I put off mobile development for web app development which could be scaled to work for mobile browsers using a blend of frameworks like Bootstrap, Foundation, AngularJS, and Node.js. Of course, making a mobile web app had some drawbacks. It loaded slower and would always need a connection to the internet in order to fetch the pages.
That changed recently when I was re-introduced to Cordova and PhoneGap as well as the Ionic Framework. I had heard about Cordova when I was working with Objective-C but after a quick initial investigation, decided that it wasn’t for me due to the limited functionality in the earlier days. After a deeper dive this time, I’ve begun to see it as a platform that I can develop for.
The biggest issue I reached early on was the need to talk to APIs and the CORS (Cross-Origin Resource Sharing) issue. Because some APIs don’t expect to be called client-side (which is what you code for in a Hybrid app), this causes some development pains. Rendering in the browser allows for fast iterative development and better debugging without having to rebuild each time, but will regularly throw the CORS issue in your face, while deploying to the phone will work perfectly fine but limit your debugging capabilities. To circumvent this, you need to open a new browser window with web security turned off (which is dangerous, so only use it for your application). More info on how to do this can be found here: http://superuser.com/questions/593726/is-it-possible-to-run-chrome-with-and-without-web-security-at-the-same-time
After that, I was in the free and clear and I’m starting more mobile development again.
I have a friend who is really into Virtual Reality development and he introduced me to the Google Cardboard Kit. Google Cardboard is able to enable accessible VR tools through the use of smart phones as the basis for the platform. Since most people have smart phones, but very few have VR headsets, a simple and cheap conversion add-on was beneficial. I figured that with its cheap barrier to entry, I could at least test it out and as soon as my kit arrived, I started to do a bit of development for my iPhone 5 in Unity for it.
I got this kit for $26 and unlike the other cardboard ones, this was made of plastic and had better construction with adjustable focus and lens separations.
Here are some of the thoughts I had while developing for and trying out the Google Cardboard SDK for Unity:
It’s awesome for game developers because it provides them with an easy way to take a 3D game and turn it into a VR experience! (as long as its been developed in Unity)
BUT theres a very limited way to interact with applications right now (aside from moving your head). The only real interaction is to use the “trigger” which is a magnet on the side of the headset. I’ve seen videos of people hooking up controllers to their Android phones, but it would be amazing if there were better guides on how to set up a wireless controller, Leap Motion, or Myo armband for interactions from a developer standpoint.
The Unity SDK really limits the functionality of the applications right now. For example, it’s almost impossible to figure out how to stream video to it from a server, or create a simple socket connection to a server in order to provide input / data. (I am trying to use the headset to move a servo that is connected to a WebCam for remote viewing)
Overall, I learned a lot going into a quick dive into developing a Unity application and using the Google Cardboard SDK, but I’m not sure that it’s ready yet for me to go much further. The biggest issues for me are the limited interaction and the lack of a usable cross-platform networking stack. I’m sure that it will get better, but for now I’ll just have to be happy playing a couple simple games and watching Youtube 360 videos.
If you want to see what I did as an entry point:
I used this “Roll-a-Ball” tutorial in order to get accustomed with developing in the Unity environment before I built this VRCameraDemo that take my phone’s back facing camera and places it on a plane in front of the viewer to recreate what it sees. (Not very “virtual” reality)