codefox421

I assume you mean the difference between brake and float. Yes there are a couple ways: Firmware mod: Replace line 281 of brickster8884bt.ino with digitalWrite(mcPin1X, (*levelX > 0 ? HIGH : LOW)); and line 282 with digitalWrite(mcPin2X, (*levelX < 0 ? HIGH : LOW)); App mod: Replace line 160 of BricksTer.java with public static final byte RED_STOP = 'P'; and line 167 with public static final byte BLUE_STOP = '`'; You can use either method, but I would suggest the firmware edit. It will cause the receiver to act the same way no matter what version of the app you are using to control it. Yes, you can definitely do this. I thought changing the firmware would be easier than changing the hardware, but either works. If you go this route, be sure to cut the two traces for the channel you won't be using between the ATtiny84 and the DRV8833. Here you go: https://www.dropbox....ing-04-best.apk

I see. You're using two receivers in parallel to overcome the separated red/blue output channels (and potentially current protection on the battery boxes?) You could tweak the BT receiver's firmware to control both red and blue output channels with only one (ex. red) input channel. The driver chip should be able to support that load, your PWM waveforms will be synchronized, and you'll only need one BT receiver! In fact, it uses the same driver chip as version 2 of LEGO's IR receiver. Thanks to Philo for figuring that out and posting it on his website: http://www.philohome...pfrec/pfrec.htm It's a little unfortunate though. I liked the TB6612FNG's 15V maximum and the 11.1V 3S lipos I could use with it. Oh well!

Checked the datasheet to be sure: it has over-current, thermal-overload, and under-voltage protection.

I've been considering it. It will take a little while before I'm comfortable selling any; I haven't even assembled a rev. 2 board yet! (waiting on some orders) Hm... I need to find a better way of documenting that. Anyway, I've had success sourcing mine from iTead. Expect long lead times though. I've heard of other people buying them from DX, but I haven't tried. DX is a little cheaper if you're buying three or more (wish I had known a couple days ago). They probably have long lead times too, but I don't know. If you choose DX, please let me know how it goes.

I'll forgo the PM in the name of openness, but post in the Bluetooth receiver topic to keep from going off-topic here. http://www.eurobrick...25#entry1917768

It feels better to post this here instead of going off-topic elsewhere. You can order them straight from OSHPark here: https://oshpark.com/...ojects/jNrizzs2 or download the BRD file for editing with EagleCAD (6.5 is what OSHPark uses). Here's the BOM for ordering parts. A programmer is also needed if you don't have one (I suggest AVRISPmkII), and pogo-pins are helpful. Firmware tweaks for the new board revision may take some time as the PCBs I ordered are still being fabbed. I make no money from the above links; I'm just excited to maybe get my device into someone else's hands! Please let me know how it goes.

Hi Stu, I've been designing a Bluetooth alternative to the IR receiver. It doesn't have quite the tiny 2x4 footprint of the Hack Van De Dam receiver, but at 3x4 it's not far off. Here's more info: http://www.eurobricks.com/forum/index.php?showtopic=87340&hl= Here's a video of it used in a train: http://www.eurobricks.com/forum/index.php?showtopic=93663&hl= Here's the repository: https://github.com/codefox421/brickster Rev. 1a is tested and works well; it's what I've used in my Emerald Night. However, its ability to handle current falls between the v1 and v2 IR receivers (and, I almost forgot, it has a 4x4 footprint). I've just ordered all the parts to build a few rev. 2 prototypes. Rev. 2 achieves a true 3x4 footprint and uses the same chip as the v2 IR receiver, thus handles more current than rev. 1a (though less voltage). Best of all, it's reprogrammable. Leave off the Bluetooth module (or don't), add a few sensors on the ATtiny84's leftover ports, program it with Arduino, and you've got yourself a little LEGO robot. =)

I've always found BrickLink's or eBay's prices for straight track are higher per section than S@H. Curved track you can usually find fairly cheap, but it's often the case to have an abundance of curves and not enough straights. YMMV. Here's a link to the topic with more information about the ME track: http://www.eurobrick...showtopic=94625

I would like to learn more about Jopiek's RFID solution too. I discovered this old topic a little while back, but picardgk mentioned an issue about reader latency and didn't mention specifics of the RFID hardware he was using. It sounds like he may have resolved the latency issue, but knowing that doesn't help much without knowing what reader/tags he used. I'm in the process of developing an open source Bluetooth replacement for the IR receiver. It works well enough and solves some of the issues of IR, but introduces others like the necessity of identification for automation. Using standard PF IR, you could just transmit on all four channels at once, but it would limit the system's finesse, which is not very desirable.

It's really awesome seeing your work come together! Fantastic show! I've noticed some trains' lights appear to brighten before the train starts moving. The trains also seem to come to rather graceful stops. Have you done something special to achieve this? Nice! I was looking forward to another video. What music have you used in this? I really like it.

17 hours remaining and only $12,923 to go! I was rather doubtful yesterday, but now I'm really thinking this is possible!

I think that's the point. If it were not exclusive, it would not be special. FWIW, I've upped my pledge. It's getting down to the wire (less than 3 days left!), and there's still progress to be made. It's a shame this hasn't been posted to the frontpage for more visibility.

Don't forget: no pledge is too small! Even just a few dollars helps ME Models get closer to their goal. If they achieve their goal, you'll be able to buy the track from them whenever you like!

Wow! this is really exciting. What type of sensors are you using to detect the trains? I really like the idea of a "dumb" loop with "smart" isolated sidings. Any reason you chose to have two stopping-blocks before one crossing and only one block before the other? Can't wait to see it working!

Agreed. I was rather overwhelmed at the veritable array of options presented for a Kickstarter project. I've added my support for what it's worth, and I'm glad to see a link posted on reddit, though it's sad to see the rather harsh criticism and skepticism this has met there.

I've been meaning to investigate this for quite some time now, but your post reminded me of the need to spring into action. Thanks for that! The bluetooth spec defines two limits: maximum active connections is 7, maximum inactive connections is 248. However, it's also hardware dependent. My phone may only be able to achieve 3 of those theoretical 7 active connections, while someone else's may be able to achieve all 7. As a proof of concept, I threw together a modification of the android app tonight which allows for multiple simultaneous connections (something I had already achieved with NXT quite easily). The multi-connect feature will definitely need some love before it's ready for the wild, but perhaps I can take a quick video in the morning. It's been a long day and sleep is calling. <( z z Z Z )

I've seen it before, but it never went into production as far as I know. I've been working on a similar device, which is open source.

5: 2 12: 2 21: 2

4: 1 30: 3 39: 2

I did. Additionally, NWSL sent along a batch of 10 wheels with the proper specs. (Of course, this was after I had shaved down as many of the original 12 as I needed at the time.) I was very surprised to find the new wheels in the mail since NSWL had implied that they would not fix the mistake.

It's unfortunate that +/- 7 is as fine of steps as we get, but good to know what these PF commands actually do. Thanks Duq!

Something about that PDF seemed different from what I was used to. It appears to be the v1.0 spec. I was thinking of the "Increment numerical PWM" and "Decrement numerical PWM" commands as seen on page 9 of the v1.20 spec: http://cache.lego.co...er_Download.pdf Since it appears in addition to "Increment PWM" and "Decrement PWM," I would think it differs from the +/- 7 steps in some way. Thoughts? It might be worth testing. Maybe the v2 receivers implement the v1.20 spec?

On page 10 under "Clear/Set/Toggle" mode, there are commands "Increment PWM" and "Decrement PWM". I do not own a PF receiver, so I wonder if anyone has played around with these commands? Maybe they can give finer resolution than the stock +/- 7 steps.

Seeing as we can achieve 72 stud and 104 stud radius curves using existing track without modification, I think an 88 stud radius curve would be the best starting point. That way parallel tracks with better aesthetics than #12 can be achieved with only one new radius. As for plastic vs metal, I was originally leaning toward plastic, but seeing as metal doesn't exclude PF users whereas plastic excludes 9v uers, I think I would prefer metal. Maybe do a kickstarter for plastic with a stretch goal of metal? I think that would be the best. Second radius to be produced could be 56 stud radius, so all radii are attainable without modification. Third and fourth radii produced could be 72 and 104 (not necessarily in that order) and would serve to replace curve+straight solutions. Based on all this, I have voted 88 metal. I would suggest including in the mold a label of what radius the track is. That way if you end up producing more than one radius, we will have a super easy way to tell them apart.

I've been giving consideration to the command set the receiver will recognize. Here are my current thoughts: http://codepen.io/anon/pen/Kirqj What commands would you add? Are there commands listed that seem unnecessary? To summarize some of the things being discussed elsewhere, here is a revised command architecture: http://codepen.io/anon/pen/nxhzt/ It has also been mentioned that there are 3 microcontroller I/O pins plus 3.3V board power on the programming header, which could be used for auxiliary functions (e.g. LEDs).