[HELP] Power Functions BT Receiver

[legoman666]

Looks great! I've built ... 6? of the controllers so far. Enough that selecting a specific one in the app to connect to is a guessing game.

[OzShan]

The case looks good, nice and compact. As a classic technic fan, the studded case would suit me just fine. Easy to add holes if needed as you say. Really stoked that it uses NXT compatible BT. That was a big let down for me with SBrick.

So can I buy a kit yet? :)

[codefox421]

Yaa the normals are backwards, ahah. That wasn't my fault, checked my model and is all good.

Yep, that was me, not you. I will look into eventually, but there are less-cosmetic things to work on right now.

Looks great! I've built ... 6? of the controllers so far. Enough that selecting a specific one in the app to connect to is a guessing game.

It's been on my mind to extend the firmware so as to alleviate the guessing game. I just haven't had the time to develop it yet. You could take a stab at it. This outline gives an idea of where it fits into the protocol (under "Program Mode"): http://codepen.io/niaconis/full/CawKD/ The AT command for the Bluetooth module is

AT+NAMEdevice_name

(where device_name is the name you want it to show up as) and the response is

OKdevice_name

The case looks good, nice and compact. As a classic technic fan, the studded case would suit me just fine. Easy to add holes if needed as you say. Really stoked that it uses NXT compatible BT. That was a big let down for me with SBrick.

So can I buy a kit yet? :)

You could say Mindstorms compatibility has been paramount from the start. I started this project after reading an exciting comment (on a LEGO Cuusoo post) that outlined the benefits of having a Power Functions Bluetooth receiver by referencing its use with Mindstorms. I'm sure SBrick chose BLE because it's the path of least resistance to iOS support.

A kit designed to be inside a case isn't ready yet, but I could sell you some PCB-only prototypes. PM me if you're interested.

[legoman666]

I can also whip up a couple PCBs if anyone is interested. I bought the parts for 12 by now and have only made about half.

As for the names, Android lets you rename paired BT devices, but for some reason the new names are not showing up in BricksTer.

[brckgrl]

This is really awesome. I love how it's all open source.

Some thoughts on the form factor... What about something that connects directly to the battery box, saving you the need to run the pf wires. And it could then be bigger and thus allow for more outputs. If enough extra space, maybe even a speaker could be included.

Also consider adding outputs for led lighting, a 2x2 stud space should be able to easily hold 8 instead of the 2 you get with PF. See lifelites so an example.

[codefox421]

This is really awesome. I love how it's all open source.

Some thoughts on the form factor... What about something that connects directly to the battery box, saving you the need to run the pf wires. And it could then be bigger and thus allow for more outputs. If enough extra space, maybe even a speaker could be included.

Also consider adding outputs for led lighting, a 2x2 stud space should be able to easily hold 8 instead of the 2 you get with PF. See lifelites so an example.

It looks like lifelites uses JST connectors... maybe JST-ZH.

It should be easy enough to respin a board to use those specific connectors. You might look into using a shift register though, so you can control more outputs with the one micro-controller.

[brckgrl]

It looks like lifelites uses JST connectors... maybe JST-ZH.

It should be easy enough to respin a board to use those specific connectors. You might look into using a shift register though, so you can control more outputs with the one micro-controller.

I don't really have much electronics experience :( so I don't really follow what you are proposing. But more outputs with just one microcontroller would be awesome. :) are you saying like maybe an add on piece that would expand the outputs, or control the lifelites, or make sound? That could work.

I can program however, so I'm happy to help with that in any way I can. I wouldn't worry about iOS too much, in my experience most makers use android.

[joblog]

Fascinating stuff, congratulations to you all.

I only have experience getting a HC-05 Bluetooth module to work with an Arduino board.

While the module works happily with a 5v power input it is widely believed that the TX signal needs to be dropped to 3.3v.

The module may work with a 5v Tx signal at first but not for long.

For an Arduino board the problem is usually solved with two resistors.

So I'm asking (i) does the battery supply 5 volts to the signal wire

(ii) does your redesigned bluetooth module incorporate a level shift and work with a 5v Tx signal input (in which case it would be of interest to arduino people even without your nicely designed lego block)

Well done again

[TheNextLegoDesinger]

I've put together an open source solution for controlling Power Functions using Bluetooth. Back when I started this, I had heard of the upcore, but it promised to be expensive and do a lot more than necessary. (Now that project doesn't even seem to exist anymore.) I've designed more of a 1:1 replacement for the standard PF IR receiver.

Go here to find all the delicious source files: https://github.com/Btbricks

Reading the readme can help in getting started: https://github.com/B...aster/README.md

Here is a video of a very early prototype:

I've built an Android app that looks just like the Power Functions remotes:

I'd love to hear your thoughts about different app designs that could be useful.

The cost per device is about $26.

Everything squeezes into the inside of a theoretical 3x4 brick.

I'm working on designing an enclosure (read: flashy plastic box), so please tell me what you would be looking for in terms of how it integrates with other LEGO bricks.

Thanks!

P.S. I'm trying to keep things licensed under an MIT license as much as possible. It is the most open of open source licenses!

P.P.S. This topic is maybe inadequately named now.

Sbrick already has an concurrent

[codefox421]

Fascinating stuff, congratulations to you all.

I only have experience getting a HC-05 Bluetooth module to work with an Arduino board.

While the module works happily with a 5v power input it is widely believed that the TX signal needs to be dropped to 3.3v.

The module may work with a 5v Tx signal at first but not for long.

For an Arduino board the problem is usually solved with two resistors.

So I'm asking (i) does the battery supply 5 volts to the signal wire

(ii) does your redesigned bluetooth module incorporate a level shift and work with a 5v Tx signal input (in which case it would be of interest to arduino people even without your nicely designed lego block)

Well done again

Hi joblog! Thanks for you interest in the project.

The signal wire uses 3.3 volts. It is within the operating range of the microcontroller, and allows the Bluetooth module to be used as-is. I have not redesigned the Bluetooth module.

I've let this project decay somewhat recently, but this year I'm picking up where I left off. My aim is for a cadence of 1+ commits per week. I will be rebuilding the app from the ground up and doing some redesign of the electronics, potentially spinning off a second form factor that uses JST ZH connectors.

[joblog]

Ok I think I've got it.

The battery pack supplies 9v to your brick.

Your brick contains an ATtiny84 microcontroller

It has a regulator to drop the voltage and I am assuming you are running the ATtiny at 3.3v.

The HC05 Bluetooth module is a 3.3v device

The microcontroller also contains a DRV8833 motor bridge.

Each motor connects to an xOUT1 and xOUT2 pin of the bridge using Lego connectors that attach to the top of your brick.

It is amazing you got all of that inside a Lego brick.

It's especially impressive that there is an ATtiny84 in there.

So, questions;

1 Seeing as the brick contains an ATtiny84 it seems a shame not to have access to its other pins. Could these be broken out on top of the brick also? Sensors could be attached using Lego connectors.

2 Could bluetooth be used to upload sketches to the ATtiny84?

(This is a bit speculative. You can certainly upload sketches to most arduino boards over bluetooth, there are even apps that do it. Whether the same applies to an ATtiny84, I don't know.)

Well done again.

[codefox421]

Ok I think I've got it.

The battery pack supplies 9v to your brick.

Your brick contains an ATtiny84 microcontroller

It has a regulator to drop the voltage and I am assuming you are running the ATtiny at 3.3v.

The HC05 Bluetooth module is a 3.3v device

The microcontroller also contains a DRV8833 motor bridge.

Each motor connects to an xOUT1 and xOUT2 pin of the bridge using Lego connectors that attach to the top of your brick.

It is amazing you got all of that inside a Lego brick.

It's especially impressive that there is an ATtiny84 in there.

So, questions;

1 Seeing as the brick contains an ATtiny84 it seems a shame not to have access to its other pins. Could these be broken out on top of the brick also? Sensors could be attached using Lego connectors.

The other pins could be broken out of the sealed unit, but doing so on the top would interfere with the stud connections. They are already broken out on the naked PCB. So far, it's only been used for programming access. See the 2x3 header connection on this PCB:

2 Could bluetooth be used to upload sketches to the ATtiny84?

(This is a bit speculative. You can certainly upload sketches to most arduino boards over bluetooth, there are even apps that do it. Whether the same applies to an ATtiny84, I don't know.)

It's technically possible, and I investigated it at one time. The trouble is, programming the microcontroller wirelessly has the potential to corrupt the code unless you use an error catching method (checksum). Before doing a checksum, the entire program must be stored on the brick, but there isn't enough memory in the ATtiny84 for that (except in the flash space, but that would wipe the old program before doing the error check on the new one), so it requires an external storage chip. There isn't enough physical space inside the brick for the extra memory, unless the brick is made larger. Additionally, loading the program wireless with or without error checking requires a bootloader to be present on the microcontroller, and writing a bootloader wasn't really something I had planned for this project.

That said, I'm planning a new version of the receiver which will use a better microcontroller (either the ATtiny841 or the ATmega32u4; I haven't decided which yet), and I'm reinvestigating ways to program the microcontroller. If I go with the ATtiny841, I will be forced to use C instead of Arduino Processing, but that will give me a reason to reinvestigate wireless programming.

Well done again.

Thanks!

[__________________________]

I've put together an open source solution for controlling Power Functions using Bluetooth. Back when I started this, I had heard of the upcore, but it promised to be expensive and do a lot more than necessary. (Now that project doesn't even seem to exist anymore.) I've designed more of a 1:1 replacement for the standard PF IR receiver.

Go here to find all the delicious source files: https://github.com/Btbricks

Reading the readme can help in getting started: https://github.com/B...aster/README.md

Here is a video of a very early prototype:

I've built an Android app that looks just like the Power Functions remotes:

I'd love to hear your thoughts about different app designs that could be useful.

The cost per device is about $26.

Everything squeezes into the inside of a theoretical 3x4 brick.

I'm working on designing an enclosure (read: flashy plastic box), so please tell me what you would be looking for in terms of how it integrates with other LEGO bricks.

Thanks!

P.S. I'm trying to keep things licensed under an MIT license as much as possible. It is the most open of open source licenses!

P.P.S. This topic is maybe inadequately named now.

Would this increase the range of the lego IR receivers, or the power delivered to the motor?

[codefox421]

Would this increase the range of the lego IR receivers, or the power delivered to the motor?

The biggest advantages are it's not line-of-sight (the signals go through walls) and it has the capacity for far more simultaneous control without crosstalk (more than 4 channels).

The current designs use the same motor driver chip that is found in the V2 IR receivers, so the power delivered to the motor would be similar to those. (It's worth pointing out that Power Functions motors are limited more by the battery box than by the receiver.)

[joblog]

The other pins could be broken out of the sealed unit, but doing so on the top would interfere with the stud connections.

I see what you mean. It would require a 4x4 brick rather than your 4x3.

[uploading a sketch with bluetooth is] technically possible, and I investigated it at one time. The trouble is, programming the microcontroller wirelessly has the potential to corrupt the code unless you use an error catching method (checksum). Before doing a checksum, the entire program must be stored on the brick, but there isn't enough memory in the ATtiny84 for that (except in the flash space, but that would wipe the old program before doing the error check on the new one), so it requires an external storage chip. There isn't enough physical space inside the brick for the extra memory, unless the brick is made larger. Additionally, loading the program wireless with or without error checking requires a bootloader to be present on the microcontroller, and writing a bootloader wasn't really something I had planned for this project.

Interesting. I hadn't heard about that before. Did you run in to this in practice or did it occur to you at the planning stage?

That said, I'm planning a new version of the receiver which will use a better microcontroller (either the ATtiny841 or the ATmega32u4; I haven't decided which yet), and I'm reinvestigating ways to program the microcontroller. If I go with the ATtiny841, I will be forced to use C instead of Arduino Processing, but that will give me a reason to reinvestigate wireless programming.

You may not need to use C. There are a few people working on modifying arduino-tiny to support the ATtiny841 and make it Arduino programmable.

http://forum.arduino.cc/index.php?topic=198916.30

https://code.google.com/p/arduino-tiny/issues/detail?id=92

It seems hard to believe you could plug a servo and an ultrasonic sensor on to a tiny lego brick and wirelessly upload an object avoiding sketch. Great stuff.

[codefox421]

Interesting. I hadn't heard about that before. Did you run in to this in practice or did it occur to you at the planning stage?

Mostly at the planning stage, although I did try some error-checking-less methods without success. Here's the article where I got most of my info: http://lowpowerlab.com/blog/2013/03/29/wireless-programming-step-1-success/

You may not need to use C. There are a few people working on modifying arduino-tiny to support the ATtiny841 and make it Arduino programmable.

http://forum.arduino...topic=198916.30

https://code.google....es/detail?id=92

I know. I wrote comment #1 on that GoogleCode issue. Wireless programming would still require Atmel C though; the Arduino libraries don't include support for writing to flash memory.

It seems hard to believe you could plug a servo and an ultrasonic sensor on to a tiny lego brick and wirelessly upload an object avoiding sketch. Great stuff.

I hadn't really thought of it as a micro-robotics platform for LEGO, but I guess you're right. I will have to keep this consideration in mind when deciding which microcontroller to move forward with. The ATmega32u4 is getting tempting with it's larger flash memory and more IO pins, but I wouldn't bother with wireless programming if I were to use that chip since it supports USB bootloaders natively.

[joblog]

I hadn't really thought of it as a micro-robotics platform for LEGO, but I guess you're right. I will have to keep this consideration in mind when deciding which microcontroller to move forward with. The ATmega32u4 is getting tempting with it's larger flash memory and more IO pins, but I wouldn't bother with wireless programming if I were to use that chip since it supports USB bootloaders natively.

You obviously know a lot more about this than I do.

A couple of points:

As ATmega32U4 boards go the Pro Micro is one of the smallest. It is 1.3x0.7" or approximately a 4x2 lego brick.

If the board also has to contain a motor driver and two holes for pegs how big a brick do you think would be required?

It seems you'd need something bigger than 4x3.

If there is room to clip on four connectors it seems a real shame not to break out enough pins on top for at least two sensors as well as the two motors.

Programming over Bluetooth.

By far the best reason to enable this is just that you can, that it's possible.

You have the HC05 and the ATmega in the same brick so why not.

As I'm sure you know it's mainly just a question of whether you want to connect pin 32 on the HC05 to the reset pin on the ATmega.

(There are other changes, that connection needs a capacitor too, you need some resistors for stability, the HC05 needs to be reprogrammed, principally to change its baud rate to one suitable for programming but also a few other minor tweaks)

Why NOT do it?

Regardless of how it is to be programmed, whether over USB or Bluetooth, you are creating a huge opportunity by being able to communicate with a programmable ATmega over Bluetooth.

Anything Lego should be child friendly. Child friendly programming means something like Scratch or Ardublock and these need a permanent connection between the laptop and the Atmega.

Your Bluetooth connection means free roving RC cars and Robots. A car with a USB cable hanging out of it would be just lame.

Looking forward to seeing whatever you come up with.

[legoman666]

Keep me in the loop if you design a 2.0 controller. I'll beta test.

Will the updates with the app maintain backwards compatibility with all versions of the controller or are you just going to keep old and new separate?

Anything Lego should be child friendly. Child friendly programming means something like Scratch or Ardublock and these need a permanent connection between the laptop and the Atmega.

Your Bluetooth connection means free roving RC cars and Robots. A car with a USB cable hanging out of it would be just lame.

Looking forward to seeing whatever you come up with.

I don't think this is really for children considering it has to be assembled at home so I don't think it should even be considered a design constraint.

Edited February 8, 2015 by legoman666

[joblog]

I don't think this is really for children considering it has to be assembled at home so I don't think it should even be considered a design constraint.

Maybe we are talking at cross purposes. I am thinking of a sealed block containing the ATmega and the HC05 to which you could attach motors (and sensors). Programming would be done by USB or better still by bluetooth.

Having the option to program by bluetooth would require a slight change in the wiring between the ATmega and the HC05 and a change in the configuration of the HC05 but this would be a once off thing and done before the block was sealed.

[codefox421]

As ATmega32U4 boards go the Pro Micro is one of the smallest. It is 1.3x0.7" or approximately a 4x2 lego brick.

If the board also has to contain a motor driver and two holes for pegs how big a brick do you think would be required?

It seems you'd need something bigger than 4x3.

If there is room to clip on four connectors it seems a real shame not to break out enough pins on top for at least two sensors as well as the two motors.

I won't use an ATmega32U4 "board" like the Pro Micro. Arduino boards are, in a sense, small evaluation boards. Like eval boards, you generally don't include the whole thing in your final product. It would be overkill and overpriced. I would use the ATmega32U4 chip on a custom board; the same as I've been doing with the ATtiny84. I can likely retain the 4x3 footprint since I'll also be switching to the HM-06, which is smaller than the HC-06 I've been using.

Programming over Bluetooth.

By far the best reason to enable this is just that you can, that it's possible.

You have the HC05 and the ATmega in the same brick so why not.

As I'm sure you know it's mainly just a question of whether you want to connect pin 32 on the HC05 to the reset pin on the ATmega.

(There are other changes, that connection needs a capacitor too, you need some resistors for stability, the HC05 needs to be reprogrammed, principally to change its baud rate to one suitable for programming but also a few other minor tweaks)

Why NOT do it?

I'm afraid I don't know as much as you about programming over Bluetooth. Can you point me toward any articles or tutorials, and/or can you explain what you would do so I can try it?

Regardless of how it is to be programmed, whether over USB or Bluetooth, you are creating a huge opportunity by being able to communicate with a programmable ATmega over Bluetooth.

...

Your Bluetooth connection means free roving RC cars and Robots. A car with a USB cable hanging out of it would be just lame.

I agree. It's exiting to think that the receiver is basically a micro version of a Mindstorms programmable brick.

Keep me in the loop if you design a 2.0 controller. I'll beta test.

Will the updates with the app maintain backwards compatibility with all versions of the controller or are you just going to keep old and new separate?

I don't think this is really for children considering it has to be assembled at home so I don't think it should even be considered a design constraint.

The question is "when" rather than "if". The ATtiny84's lack of hardware serial is killer, which means the only way to move forward is to upgrade microcontrollers. If I use the ATtiny841, it could be swapped in place of the ATtiny84 on older receivers; they have the same pin-out or at least it should be close enough. (I will have to look into which ATtiny841 pins have hardware serial on them.) I'm kind of hoping this update to the ATtiny Arduino core gets completed before I have to settle on one microcontroller or the other. It would make my life a lot easier. I've emailed Michael to offer my help, but haven't heard back in a while.

I will probably break backward compatibility in this case. The old protocol was based on the restriction that all commands are one byte long, which has proven to be very limiting but necessary because of software serial on the ATtiny84.

[joblog]

I won't use an ATmega32U4 "board" like the Pro Micro.

Given what you've already managed to do I didn't think you would be using someone elses board. I was just looking for an estimate of how big a board containing some of these things would be.

What kind of options are there for connecting motors and/or sensors? I know there are a number of things to consider; size, aesthetics, keeping a lego 'look' (or not)...

programming over Bluetooth. Can you point me toward any articles or tutorials

Ok you asked for it.

There are two main issues.

One. You need to reset the baud rate on the HC05 to the rate at which the Arduino can be programmed.

Two. When you make a new USB connection to an Arduino board the board resets and the bootloader looks to see if there is a new program to be installed.

When you make a new Bluetooth connection this doesn't happen. On the other hand pin 32 on the HC05 becomes active. If you connect pin 32 to the reset pin on the Arduino the bootloader will go looking for a new program to load like happened with the USB. Happy days. There are a few tweaks but that's the general idea.

At the moment the most popular description of how to set things up seems to be this one

http://makezine.com/projects/diy-arduino-bluetooth-programming-shield/

That tells how. As for why, the same author describes the thinking behind some of those steps in the first answer here.

http://arduino.stackexchange.com/questions/1618/programming-arduino-via-bluetooth-module-issue/1757#1757

Also useful, the person who seems to have originated the method describes it here

http://letsmakerobots.com/node/30915

It's exiting to think that the receiver is basically a micro version of a Mindstorms programmable brick.

Yeah. Even just programming over USB, if you can put a lego brick like that in the hands of kids everywhere for cheap, that really is something.

[legoman666]

The question is "when" rather than "if". The ATtiny84's lack of hardware serial is killer, which means the only way to move forward is to upgrade microcontrollers. If I use the ATtiny841, it could be swapped in place of the ATtiny84 on older receivers; they have the same pin-out or at least it should be close enough. (I will have to look into which ATtiny841 pins have hardware serial on them.) I'm kind of hoping this update to the ATtiny Arduino core gets completed before I have to settle on one microcontroller or the other. It would make my life a lot easier. I've emailed Michael to offer my help, but haven't heard back in a while.

I will probably break backward compatibility in this case. The old protocol was based on the restriction that all commands are one byte long, which has proven to be very limiting but necessary because of software serial on the ATtiny84.

I'm of the opinion that that hardware is perfect as is. Adding more just makes it unnecessarily complicated; a straight bluetooth copy of the v2 receiver is perfect. It's only the app that I wish was more fully fleshed.

Unrelated, how many folks have actually made these besides me? I passed out a few to some LUG members and they like them. People I met at Lego shows liked them, but weren't too keen on the 'solder at home' requirement. Also, will you make your case on shapeways public so we can buy it?

[codefox421]

I'm of the opinion that that hardware is perfect as is. Adding more just makes it unnecessarily complicated; a straight bluetooth copy of the v2 receiver is perfect. It's only the app that I wish was more fully fleshed.

The trouble is the SoftwareSerial library, which is necessary when using the ATtiny84 since that microcontroller doesn't support hardware serial. If you happen to be writing to SoftwareSerial while data is coming in, the incoming data gets corrupted. Obviously, if the incoming data is corrupt, the receiver won't be responding to the commands you were sending it. It will be responding to garbage commands, some of which will look like real commands, and thus will result in the receiver responding to commands that the user did not send. I call this the "phantom commands" issue, and it took me a really long time to track down what was going wrong because it's so intermittent.

The "solution" was to place a lock on the Bluetooth connection after sending a command and wait for the receiver's response before releasing the lock, thus allowing subsequent commands to be sent (links go to the lines of source code where these things happen). This works because the receiver goes quiet (not writing data to serial) after it has sent its one-byte response, and therefore the next command the app sends won't be clobbered by the receiver's response stage. However, this "solution" means that if the app somehow misses the receiver's response, it becomes locked up and must be restarted (cleared from the recent apps and reopened).

Now I've been saying "solution" (with quotes) because the REAL solution is to replace the ATtiny84 microcontroller with one that supports hardware serial. That way data can be sent and received simultaneously without clobbering the incoming commands, which keeps the app from having to do hacky things and potentially locking up. With that also comes the potential to send/receiver more data. For instance, the app could poll the receiver for what firmware version it's running and use different command sets for different receivers running different firmware versions or even with different hardware components. Many things become possible that just aren't possible while stuck using the ATtiny84.

Additionally, I want to replace the input/output solder pads with vias, so that it's easier to solder PF cables to the board or metal bits if using the enclosure.

Unrelated, how many folks have actually made these besides me? I passed out a few to some LUG members and they like them. People I met at Lego shows liked them, but weren't too keen on the 'solder at home' requirement. Also, will you make your case on shapeways public so we can buy it?

I should do that. I can't just yet, because the connection geometry is a direct copy of LEGO's at the moment. However, now that I know everything is situated correctly, I should be able to change the surrounding shape and open it up to be purchased.

[codefox421]

I should [offer the case for sale on shapeways]. ... I should be able to change the [connector] shape and open it up to be purchased.

I probably should have gotten some much needed sleep, but instead I did this. Ask and ye shall receive, I suppose.

www.shapeways.com/.../brickster-case

Go to https://github.com/B...cc00b3a7e4ca27c and switch to "Revision Slider"... it's a pretty cool way to look at the difference between old and new versions.

Do you think it's enough of a change?

[legoman666]

I probably should have gotten some much needed sleep, but instead I did this. Ask and ye shall receive, I suppose.

www.shapeways.com/.../brickster-case

Go to https://github.com/B...cc00b3a7e4ca27c and switch to "Revision Slider"... it's a pretty cool way to look at the difference between old and new versions.

Do you think it's enough of a change?

Link to Shapeways didn't work. Whats the issue with your original case? There's a ton of 3d printed stuff that looks like Lego. What makes the connector specifically verboten to copy?