codefox421

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. 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.

Woot! Finally! I'm excitied. :D Any reason why you chose to fulfill all the plastic-only orders before fulfilling the plastic portion of any mixed orders even though you are splitting mixed orders into separate plastic and metal shipments?

I didn't notice that at first either. Good job making your custom rails fit in perfectly with LEGO trains!

Yet the tan windows are the most expensive part. Economical recolors basically have to be any-color and not-tan, which often doesn't look as nice as the tan equivalent.

My 2¢: I like the ones with vertical tiles on the sides. They break up the monotony of the long horizontal lines and give it the feeling of more structure/framework.

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. 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? I agree. It's exiting to think that the receiver is basically a micro version of a Mindstorms programmable brick. 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 personally prefer the one on the right with the curved beams. Looks stunning! Do you have a way to keep the buffer beam from flipping upward? I can't tell from the photos.

I made this using SketchUp, and it printed okay: https://www.shapeways.com/product/RMEMYNGSK/?key=ea32833352d8e409e982b2c6b1df137f I did have to be really careful when creating it though. SketchUp does magic things in the background, and sometimes they mess things up really good.

I've used them in place of the normal rounded ones. Take a look here: http://www.eurobricks.com/forum/index.php?showtopic=97927&view=&hl=&fromsearch=1

11.1V may be within the safe operating range of the motors, but the motor driver chip in the IR receiver maxes out at ~10V if I recall correctly. Not to mention a fully charged 3 cell LiPo is closer to 12V. I may have looked into this at one time.

"Sorry, you don't have permission to perform this action." I look forward to your report.

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/ 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. 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.

Thanks for the great review! I'm getting increasingly excited to receive mine. Maybe I should have backed twice, once for plastic and separately for metal, instead of tacking metal track onto my order. Oh well. By the way, wouldn't it be better to link directly to your article? http://railbricks.com/blog/me-models-custom-track-a-review/ I backed the project, so I'll be getting some plastic and some metal rails eventually. They haven't shipped yet, but I'll have to bring them to a meeting once they arrive.

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.)

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: 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. Thanks!

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.

I sure hope ME Models is watching this thread. It would be great if they created something like this next. You could even electrify only a small portion of track and use a battery that recharges as the train rolls over that section. The rest of the layout could be cheaper plastic track. Maybe that's why ME chose to limit the types of metal track they produce...

I've found the EN needs a little more modification that what's detailed in RailBricks. I focused my attention mainly on the back truck and got it to run well up and down inclines. Maybe I should do a write up sometime. Anyway, it still has trouble pushing things; there's not enough weight over the front truck. Solving that ought to be my next EN project.

Have you heard of the BTbricks project or SBrick?

Spectacular station! It may not be physically attached to the building, but the real wow-moment for me was noticing the embossed writing and engraved train carving above the tunnel portals.

I'm surprised to see how hollow it is. Great job capturing this iconic locomotive!

And a terrible feature for developers. It basically meant small-time groups like the SBrick devs couldn't build hardware for Apple devices. (Or at least doing so was very cost prohibitive) Thankfully Apple didn't make the same mistake with BT 4.0

Or skip the wait and go open source: https://github.com/BTbricks http://www.eurobrick...showtopic=87340

I hear you and believe you. Still, it would have been nice to have seen an official update when they didn't hit their mark (or when they started shipping; I guess I don't know which happened since there was no update )

I would also like to know. The last update was mid-November and said "we should have in-stock and begin shipment of the plastic rail products before the end of the month." It's well passed the end of that month. Have you started shipping?