# The Open-Source-Bluetooth-Train-Control Thread



## RT_Coker

This thread is for public announcements from the “Open-Source-Bluetooth-Train-Control” Group.

You can find this group here: http://www.trainboard.com/grapevine/group.php?groupid=125
“The initial interest of the group will be the development of Direct-Bluetooth-Locomotive-Control (hardware, embedded-software, and iDevice software) for HO scale locomotives that use this group’s TBD open-source-communications-interface. “ 

It is also a place for open discussions of this group’s activities and interests.
Bob


----------



## RT_Coker

*Initial Moderator RT_Coker*

The “Open-Source-Bluetooth-Train-Control” group is “moderated”, that is open to members who are interested in contributing to the development of Open-Source-Bluetooth-Train-Control. This group includes and encourages the participation of manufactures and members of other open-source organizations. It discourage (and will limit were feasible) the inclusion of members:
1)	That is (or appear to be) ultimately unidentifiable.
2)	That is not recognizable as an interested contributor.
3)	That fails to clearly declare their financial or other open-source interests to this group.
4)	That publically releases this group’s information without prior approval from this group.
5)	That meets other criteria as determined by this group.

I am the initial moderator (by default and by being the initiator). It is my intent to only be the moderator as needed to get this group up and running. 

It is my intent to start a more formal organization of the group by vote of the majority of the members of the group, when the group has more than 20 active members.

I have no (and plan to have no) financial interest related to this group’s interests. My only other connection to open-source is at Atmel Spaces. 

I am an old retired embedded programmer/systems-engineer, and am new to the hobby (~3 years). You are welcome to research my posts as a poster named RT_Coker on this train forum and others. My main interest is as a user and in the embedded-software that executes on the Bluetooth-Locomotive.

I have taken exception to the past business practices of one hobby manufacturer, but I would not hinder them from joining this group. After all, I have a lot of their DCC products, and a strong desire to help the users of such products.

If you have questions about joining this forum that you want me to try and answer, I suggest that you post a message in this thread or send me a private-message on this forum.

Thank You!
Bob


----------



## DonR

Bob

Thank you for keeping us up to date on the Blue tooth system.

I think it's going to be getting more and more attention as
folks become aware of it, especially since it can be used
in conjunction with existing DCC systems.

Don


----------



## RT_Coker

DonR said:


> Bob
> 
> Thank you for keeping us up to date on the Blue tooth system.
> 
> I think it's going to be getting more and more attention as
> folks become aware of it, especially since it can be used
> in conjunction with existing DCC systems.
> 
> Don


Thanks Don,

This thread is not about the announced bluetooth-locomotives. It is about doing something like the NMRA-DDC-specifications for the emerging applications of bluetooth in the hobby.
Bob


----------



## DonR

Bob

Now I'm confused. I thought the blue tooth system you
are discussing is a cousin of the Bachmann Bluetooth decoders and
that both work in conjunction with existing DCC systems.

Is this not true?

Don


----------



## RT_Coker

DonR said:


> Bob
> 
> Now I'm confused. I thought the blue tooth system you
> are discussing is a cousin of the Bachmann Bluetooth decoders and
> that both work in conjunction with existing DCC systems.
> 
> Is this not true?
> 
> Don


Don,
This thread (misspelled tread) is for discussion about ***forming*** an “Open-Source-Bluetooth-Train-Control” Group for doing something like the NMRA-DDC-specifications for the emerging applications of bluetooth in the hobby. It is not about anybodies particular system, “the Blue tooth system”. The idea is to bring as many parties together as possible to produce a common interface(s). In other words, this tread is not about what Bachmann or I am doing to further Direct-Bluetooth-Locomotive-Control.

I was just trying to keep discussions about individual particular systems out of this thread as they can (and usually are) disruptive.
Bob


----------



## RT_Coker

*Why Open-Source-Bluetooth-Train-Control?*

Would you like to be able to control your trains wirelessly and directly from an iDevice or computer? [No more strange delays in your train’s responses to your commands.]

Would you like to be able to read and change CVs simply and directly from an iDevice or computer? [No more motor-pulse detection and decoding. No need for programming tracks and etcetera.]

Would you like to be able to temporarily change CVs without affecting their permanently stored values? 

Would you like to be able to run your trains on DCC, DC and AC powered track without even a CV change?

Would you like your train’s speed to be controlled accurately across the entire speed range with a simple CVs adjustment? [No tricky Back-EMF CVs!]

Would you like to have all you trains run at the exact scale speed specified by the train-controller? [No more speed-matching for good consists.]

Would you like to be able to synchronize the chug sounds on your steam engines to the piston motion across the entire speed range?

Would you like to be able to command your trains to go a specific scale distance at a specific maximum scale speed?

Would you like to be able to set your trains up to autonomously execute a set of stored commands while they send status messages, and accessory control messages to the iDevice or computer? Were the accessory messages would request, control, and then relinquish such things as track segments and turnouts from and through the iDevice or computer. 

Would you like to be able to command your trains to stop when they reach a designated spot beside the track so that they are at a know track position and can accurately keep repeating a set of stored commands?

This is not a put-down of DCC [or any current model train technology]! Yes, it could eventually put DCC products at risk [including my own recent expenditures]. 

If you or your organization is interested in one or more technical area [train H/W, embedded S/W, Apps, or ...] of this open-source approach, 
I open to ideas. I am retired and actively building a working demonstration of this approach. 

Bob


----------



## RT_Coker

**** Attention DCC Decoder Manufactures ****

Assuming that I did not misread something, you can do the Bluetooth-Licensing thing here: https://www.bluetooth.org/en-us/members/introduction-to-membership. You may want to get started before the existing Bluetooth car, airplane, helicopter, ... manufactures jump in to the model train control business.
Bob


----------



## RT_Coker

This is a test-bed-loco for open-source direct-bluetooth-train-control. It is being tested on a USB tether before having the bluetooth added. (The hardware is just pieced together parts for now.)
The test-bed-DBTC has motor-speed-control and distance-control. It can be commanded to go a specified scale-distance down to +-1 foot. As long as the loco-motor has the power, wheel-speed should not change regardless of what it is pulling. (No speed-matching needed for OS-DBTC-locomotives in consists.) Changing “CV’s” in this unit is direct and simple (no loco-movement & no problematic-signal-path). The CV’s and initial function settings can also be simply upload/download as a group. 
This gets rid of two of the biggest problems I have had using DCC.
Bob


----------



## RT_Coker

*Hassle-Free-Firmware-Updates!*

BlueTrain will now have an added feature! The user will be able to change the firmware in BlueTrain locomotives without touching or changing anything on the locomotive, layout, layout-power, or Bluetooth connection. And because Bluetooth provides a fast and reliable 2-way connection, the firmware will be faster and easier to change than a CV setting with a DCC system. (All the coding has been done and tested, just waiting for the first set of locomotive hardware for final testing and demonstration.)

This is just one example of how advanced technology (when done correctly) can be less complex than old technology.
Bob


----------



## fp45

?????????????

does this mean i can control my trains with my phone?
or just another way to use rf to control trains/other things?

not a teckie so this stuff is alien to me.

i just know when the smoke gets out, things stop working.


.


----------



## RT_Coker

fp45 said:


> ?????????????
> 
> does this mean i can control my trains with my phone?
> or just another way to use rf to control trains/other things?
> 
> not a teckie so this stuff is alien to me.
> 
> i just know when the smoke gets out, things stop working.
> 
> 
> .


Yes,
Provided BlueTrain works out, and you replace you DCC decoders with a DBTC boards. First user boards will be for HO and are about a year away.
Or you could buy a new “patent pending” (most likely a proprietary interface) HO DBTC FT-A locomotive soon from somebody else.
Bob


----------



## fp45

RT_Coker said:


> Yes,
> Provided BlueTrain works out, and you replace you DCC decoders with a DBTC boards. First user boards will be for HO and are about a year away.
> Or you could buy a new “patent pending” (most likely a proprietary interface) HO DBTC FT-A locomotive soon from somebody else.
> Bob





here i am trying to learn about dcc. and new stuff is on the way in.

other than using rf to control things, would it still be compatable with dcc?
or a change in power needs to the track?


----------



## RT_Coker

fp45 said:


> here i am trying to learn about dcc. and new stuff is on the way in.
> 
> other than using rf to control things, would it still be compatable with dcc?
> or a change in power needs to the track?


DBTC locomotives run with/on DCC without any changes.
Bob


----------



## RT_Coker

Some good information for hobbies that are interested in the future scalability of DBTC for use on large scale layouts.
[This is a large PDF and may take a while to download] https://www.csrsupport.com/download/49799/CS-316143-DC-CSRmesh.pdf
Bob


----------



## RT_Coker

*DBTC HO board, but no cigar yet!*









The picture is the first DBTC HO board with one thin-dime and an extra Bluetooth board. Don’t let the extra wires and connector freak you out they are for a debugging interface and to allow the experimental addition of new and unique capabilities. Additional details on this board will not (in all probability) be released until the boards are available in volume. 

Unfortunately the control processor is not getting data from the Bluetooth board, yet (no cigar). So we are having to backup and do a breadboard version to work this problem out. 

The HO-FTA has already been modified to add the tachometer-wheel and mounting for the tachometer-sensor. The HO-FTA also has a read-switch added (hidden) on the bottom that will be used to implement stops at precise locations.
Bob


----------



## RT_Coker

*First DBTC Locomotive Sound?*









How about an inexpensive (>$13 delivered), simple, good sounding, HO locomotive sound option for DBTC (see picture)? Just stick it on, add a removable-fake-trap and make it look like an over-sized load, and then put it directly behind the locomotive you want to have sound effects. That’s right; it is battery powered and will play sounds from any iClone. [Open-source iClone App developers, here is your chance to get in on the ground floor.] 
Bob


----------



## Cycleops

Always good to see new things coming along but can't help thinking there's a certain amount of wheel reinventing going on here.


----------



## RT_Coker

Cycleops said:


> Always good to see new things coming along but can't help thinking there's a certain amount of wheel reinventing going on here.


No “wheel reinventing” in “First DBTC Locomotive Sound?”; just using an “off-the-shelf” product. This is not even the first post of this item on a train forum.

“First DBTC Locomotive Sound?” is not intended to be a product promotion; just an example of the cost-effectiveness using high-volume-technology in the hobby.
Bob


----------



## Shdwdrgn

Not sure if anyone else saw this, but they just released a $5 Raspberry Pi computer today. This page seems to have the best details on it: http://www.element14.com/community/docs/DOC-79263/l/introducing-the-raspberry-pi-zero. Of course everybody is already sold out, but give it a month or two and there should be plenty available.

Interesting things about this board: At 65x30mm, it runs a full linux OS and has a large set of I/O ports. It runs off a basic 5V supply and apparently only pulls 160mA. It uses a micro-SD card for the OS and storage, so can easily be reprogrammed on a regular computer. And it has a standard USB port that you can use to plug in bluetooth, wifi, cameras, or other devices (imagine if every loco had an onboard camera that you could pull up on a screen).

One of the ideas I wanted to explore when I get my layout running is having each loco be fully autonomous. A board with this much power could carry a LOT of programming, so if you had sensors in the roadbed that provide location and status of the track ahead, the train could run complicated routes. Set up each loco with the basic concept of a route -- go to point A, pick up any cars from spur B, deliver cars to spur C, repeat -- and with a few trains running you could have what looks like a very complex process. If you added in the possibility of multiple routes to reach a destination a train could either wait for the track to clear or choose another path, and the interaction between multiple trains would create what appears to be a completely random process.


----------



## gunrunnerjohn

Shdwdrgn said:


> One of the ideas I wanted to explore when I get my layout running is having each loco be fully autonomous. A board with this much power could carry a LOT of programming, so if you had sensors in the roadbed that provide location and status of the track ahead, the train could run complicated routes. Set up each loco with the basic concept of a route -- go to point A, pick up any cars from spur B, deliver cars to spur C, repeat -- and with a few trains running you could have what looks like a very complex process. If you added in the possibility of multiple routes to reach a destination a train could either wait for the track to clear or choose another path, and the interaction between multiple trains would create what appears to be a completely random process.


Wouldn't that get boring? After the novelty wore off, you'd just be a spectator.  

OTOH, it would be fun to develop it.


----------



## RT_Coker

Shdwdrgn said:


> I wanted to explore when I get my layout running is having each loco be fully autonomous.


Very interesting, but the current problem (at least for HO) is not processing power but a manufactured DBTC decoder board. (The processor is an essential but small part of the board area.)

The DBTC may never “fly” for lack of a DBTC decoder board; but it is build for simple and inexpensive autonomous operation. The user decides the degree of automation and then programs the steps that the locomotive is to execute. The turnouts are switched by a DBTC-accessory-board. Multiple locomotive access to turnouts, track-sections, and other accessories are de-conflicted in the iThing controller. Automation can be none, or an uncoupling-with-push-into-a-siding, or, ... The current PIC18 in DBTC has plenty of power. It just required some careful and thoughtful firmware development.
Bob


----------



## Shdwdrgn

John, I'm a computer programmer so for me a lot of the fun is in improving the code and seeing what all I can make it do. I would include a manual override to be able to control the trains if I wanted, but when its just me by myself, having a single train running on the track would be boring. I like to see lots of action going on, and with a setup like I described above it would be fascinating to see how the various trains interact. Throw in a bit of randomness and you could have an infinite number of scenarios played out.

RT Coker -- all depends on what you want your trains to do.  I know most people prefer a more hands-on approach, but a board like this opens up new possibilities. Instead of a slow computer with minimal memory (the ardionos and teensys usually run around 256k?) you suddenly have a very fast computer 2000 times more memory and storage space in multiple gigs. It just becomes a question of how far do you want to push the possibilities.


----------



## RT_Coker

Shdwdrgn said:


> RT Coker -- all depends on what you want your trains to do.  I know most people prefer a more hands-on approach, but a board like this opens up new possibilities. Instead of a slow computer with minimal memory (the ardionos and teensys usually run around 256k?) you suddenly have a very fast computer 2000 times more memory and storage space in multiple gigs. It just becomes a question of how far do you want to push the possibilities.


Go for the “Ferrari”, I would love to see it. 
I am trying to do the mass-produced “Ford”. I probably have more on my “Ford” plate than I can handle.
Bob


----------



## Shdwdrgn

Heh, I bet. My goals are more of a "ain't that cool" sort of thing, but probably won't appeal to most people in the hobby. I don't mind, I do things for my own amusement just to see what I can do. Probably why I get into strange hobbies.


----------



## jprampolla

Hi Folks,

Just saw this on YouTube:





https://www.youtube.com/watch?feature=player_detailpage&v=SxUr8DidhZs

Nice system for the beginner. Really plug and play! (Creepy hands in the vid, however!)

Take care, Joe.


----------



## DonR

There is a post on the forum in 2015 (I think) of a video that shows a completely
automated computer controlled HO US home layout. It has several trains running, slowing,
stopping and continuing as a result of track sensing. It is a layout with
tracks crossing similar to the one in the posted video but a larger layout
with scenery. Maybe one of our sharper members can
find it.

Don


----------



## gregc

RT_Coker said:


> The current PIC18 in DBTC has plenty of power. It just required some careful and thoughtful firmware development.


firmware or centralized processing ?

i think centralized PC software (not firmware), having the capability to remotely control locomotives (e.g. DCC) and turnouts, appropriately located occupancy detection, route knowledge and virtual signalling (i.e. recognizing preceding blocks are occupied and slowing/stopping following trains), could run multiple trains on a schedule.

the intelligence is in the PC software and the available firmware in the layout and locomotives is fairly simple. Recognizing the inevitable need to stop a train rather than targeting ideal operations makes the software simpler.


----------



## RT_Coker

Thanks Joe! Very interesting!
More information from this UK web site here: www.sbrick.com. This does not appear to be an open interface and the control-app appears to come from a for-profit company.
Bob


----------



## RT_Coker

Don, Greg, & All
We all have our opinions about how automated train control should be done and are welcome to express them here. 

But “Open-Source-Bluetooth-Train-Control” is designed for automated train control using “smart”-DBTC-locomotives and “smart”-DBTC-accessory-controllers without any track-sensors nor a PC (or other computer controlling operations). It does use an iThing for user control, but is capable of running complex operations without it. It is intended to provide new capabilities while significantly reducing the cost and wiring-complexity of the typical layout.
Bob


----------



## gregc

RT_Coker said:


> But “Open-Source-Bluetooth-Train-Control” is designed for automated train control using “smart”-DBTC-locomotives and “smart”-DBTC-accessory-controllers without any track-sensors nor a PC (or other computer controlling operations).


i'm curious how this will work and would like to hear more. It puzzles me how the intelligence in the locomotive can determine that a turnout is in the wrong position or that a train is blocking its path.

i did a search for DBTC, but didn't find anything current


----------



## Shdwdrgn

I'm not sure how this project is planning on approaching the topic, but I've been doing some research for my own project with the plan of using ATtiny85 boards at each turnout and track signal. The plan is to have LED sensors on the loco for an arduino to read, and the attiny boards will send out a signal using manchester encoding.

Basically the idea is to hardwire the attinys together along each track so they keep tabs on track occupancy and turnout positions. Then using the LEDs, each location can provide an update to the loco as to what the track ahead looks like and whether a turnout needs to change positions.

The overall idea is to use a lot of little computers throughout, rather than having a single central computer controlling everything. Each loco would have planned routes with possible options (alternate routes, or picking up a car from a siding when available), and should generally be able to navigate without crashing into another train. Unfortunately I'm still working on shrinking my arduino hardware to fit inside a coal tender, so I haven't had a chance to play with the LED signalling from an attiny yet.


----------



## gregc

Shdwdrgn said:


> The overall idea is to use a lot of little computers throughout, rather than having a single central computer controlling everything.


it's easy to imagine lots of processors and small microcontrollers are cheap. But distributed intelligence and communication between them is challenging. The chip I'm working has dozens of high performance processors and sophisticated internal and external communication between them. After years of work on embedded systems with limited run-time communication, it is a joy to have a linux console to an embedded processor in order to debug it.

One problem with distributed intelligence is a change to the code requires reprogramming many processors. An advantage of centralize processing is that the intelligence resides in the PC and the embedded processor code is simple and often doesn't need to be upgraded.

Even with what I'm doing, which involves RF configuration on a multitude of different boards, each support many bands, it is sometimes more efficient to develop and test algorithms on the desktop using a simulator of the hardware and the multitude of possible configurations the hardware is capable of.

Even for a distributed environment, I think it would be helpful to build a simulation on a desktop to test concepts. Of course, it's much easier to modify, rebuild and execute code on a desktop that build it on a desktop, program it into a target and execute test on a target or multitude of targets.

when i read the threads, i'm interested in the algorithms while much of the discussion concerns the hardware.


----------



## RT_Coker

gregc said:


> i'm curious how this will work and would like to hear more. It puzzles me how the intelligence in the locomotive can determine that a turnout is in the wrong position or that a train is blocking its path.
> 
> i did a search for DBTC, but didn't find anything current


Greg,
The simple explanation is:

The DBTC-Locomotives send commands to the DBTC-Accessory-Controller(s) (by Bluetooth); they simple command the turnout to be set in the position they need. The DBTC-Accessory-Controllers control access to given track sections (turnouts, and ...) granting control to only one DBTC-Locomotive at a time and until that DBTC-Locomotive relinquishes control. When a DBTC-Locomotives request control of a track section (turnout, and ...) that is already taken, that DBTC-Locomotive waits for it to be relinquished. The iThing-User-Controller is used to gain control of (and relinquish) track sections (turnouts, and ...) that are not part of the current operations (such as track sections occupied with parked units).

Right now “Open-Source-Bluetooth-Train-Control” is a concept that may never be fulfilled. It is proving very difficult to get a manufacturer to build working DBTC-Locomotive-Boards for HO (the first step).
Bob


----------



## gregc

RT_Coker said:


> Greg,
> The simple explanation is:
> 
> The DBTC-Locomotives send commands to the DBTC-Accessory-Controller(s) (by Bluetooth); they simple command the turnout to be set in the position they need. The DBTC-Accessory-Controllers control access to given track sections (turnouts, and ...) granting control to only one DBTC-Locomotive at a time and until that DBTC-Locomotive relinquishes control. When a DBTC-Locomotives request control of a track section (turnout, and ...) that is already taken, that DBTC-Locomotive waits for it to be relinquished. The iThing-User-Controller is used to gain control of (and relinquish) track sections (turnouts, and ...) that are not part of the current operations (such as track sections occupied with parked units).
> 
> Right now “Open-Source-Bluetooth-Train-Control” is a concept that may never be fulfilled. It is proving very difficult to get a manufacturer to build working DBTC-Locomotive-Boards for HO (the first step).
> Bob


i can understand a locomotive querying some entity to determine if a block it is about to enter is clear and that a turnout it is about to cross is in a specified position.

but i don't understand how it identifies the block, the turnout or the turnout position.

you did say this was automated? this implies that the train knows its route, that the iThing is just a GUI and unnecessary?


----------



## Shdwdrgn

RT_Coker said:


> ...granting control to only one DBTC-Locomotive at a time and until that DBTC-Locomotive relinquishes control.


That's a really good method, I'll have to keep that in mind when I get to that phase in my own setup.



RT_Coker said:


> It is proving very difficult to get a manufacturer to build working DBTC-Locomotive-Boards for HO


I don't remember if you were open-sourcing your setup or not, but one way to get manufacturers interested is if you do the hard part and create an existing base of users (by letting people build their own units). If enough people are using a concept, someone will eventually approach you in an effort to monetize sales.


----------



## RT_Coker

gregc said:


> i can understand a locomotive querying some entity to determine if a block it is about to enter is clear and that a turnout it is about to cross is in a specified position.
> 
> but i don't understand how it identifies the block, the turnout or the turnout position.
> 
> you did say this was automated? this implies that the train knows its route, that the iThing is just a GUI and unnecessary?


Greg,
The blocks are identified (and assigned numbers) by the user (through the iThing) when the layout is first setup (or changed). The user (through the iThing) programs the command steps into the DBTC-Locomotive that cause it to execute the desired operation(s) starting at a know point on the layout. The DBTC-Locomotive has precision-scale-distance-control by way of a motor-tachometer, and the ability to make precision stops at the other “known” points (currently using magnets) on the layout.

The ability to quickly and effectively download new firmware to the DBTC units is already in the current firmware and operational. Control-Variables and DBTC-Locomotive “operation-programs” are also uploaded/download this way.
Bob


----------



## gregc

what does the DBTC communicate with to determine if the preceding block is clear? am I correct in believing multiple trains can operate at the same time?

maybe our definitions of automated are different and that biases my presumptions


----------



## RT_Coker

gregc said:


> what does the DBTC communicate with to determine if the preceding block is clear? am I correct in believing multiple trains can operate at the same time?
> 
> maybe our definitions of automated are different and that biases my presumptions


Greg,
I shouldn’t have used the term “block”. There are no blocks needed in this system; just “track-sections” as defined in the DBTC-Accessory-Controller(s) memory. A passing-siding would be an example of a track-section. Operations start from a known state in which the location of all locomotives and rolling-stock involved in the operations is known. And all non-operations locomotives and rolling-stock are in track-sections that are under direct control of the iThing for the duration of the operations.

No doubt the system is not the same category as existing “automated” layouts. It is intended to be simpler, more modular, and less-costly that the existing “automated” layouts. My interest is in a system that can attract new and younger hobbyists. At least open-interface (if not open-source) so that there is some healthy competition in the development of the iThing Apps.
Bob


----------



## gregc

RT_Coker said:


> Greg,
> I shouldn’t have used the term “block”. There are no blocks needed in this system; just “track-sections” as defined in the DBTC-Accessory-Controller(s) memory.


Bob
i was using the term block in the sense that a block is not clear and a signal was indicate such as on real railroads, not as in DC block control.

i understand now that the "automation" is blind to other train movements and assumes there are no conflicts.

i did a search from DBTC and thought there was a SourceForge page. Is there any description of this available on the web.


----------



## RT_Coker

gregc said:


> Bob
> i was using the term block in the sense that a block is not clear and a signal was indicate such as on real railroads, not as in DC block control.
> 
> i understand now that the "automation" is blind to other train movements and assumes there are no conflicts.
> 
> i did a search from DBTC and thought there was a SourceForge page. Is there any description of this available on the web.


Greg,
Yes, it is “blind” and requires proper locomotive operation-programs to avoid accidents. If a DBTC-locomotive is commanded into a track-section that it has not first obtained control of form its DBTC-Accessory-Controller then ...

There is a thread like this one on another forum, and there was a DBTC group on that forum before the forum was completely reworked and the groups were apparently discarded forever. 

The DBTC Source Forge section is mine and will be updated (with open read access) with all the documentation, source-code, ... that I have after I have gotten a Demonstration-DBTC-Locomotive running. Until (and if) there are usable HO-DBTC-Locomotive-Boards available there is not much that can (or should be) done in other areas of “Open-Source-Bluetooth-Train-Control”.
Bob


----------



## gregc

RT_Coker said:


> It is intended to be simpler, more modular, and less-costly that the existing “automated” layouts. My interest is in a system that can attract new and younger hobbyists. At least open-interface (if not open-source) so that there is some healthy competition in the development of the iThing Apps.


my impression is that the younger generation of game players want to interact with things. I don't understand how an automated train "can attract new and younger hobbyists", unless you think programming the route thru the iThing is the interesting part.

Even for us, I imagine the interesting part is developing the algorithms that enable the automation. Are either of us that interested in the automation itself? (I love writing code. It's like solving a puzzle).

With these things in mind, DCC reduces the interaction, the need to flip switches routing a throttle to the blocks occupied by the train. Maybe I'm wrong and the trend is for less interaction, more automation.


----------



## RT_Coker

gregc said:


> my impression is that the younger generation of game players want to interact with things. I don't understand how an automated train "can attract new and younger hobbyists", unless you think programming the route thru the iThing is the interesting part.
> 
> Even for us, I imagine the interesting part is developing the algorithms that enable the automation. Are either of us that interested in the automation itself? (I love writing code. It's like solving a puzzle).
> 
> With these things in mind, DCC reduces the interaction, the need to flip switches routing a throttle to the blocks occupied by the train. Maybe I'm wrong and the trend is for less interaction, more automation.


Greg,
The operations-programming could be very interesting depending on the accessories and sounds available and the challenge of creating realistic-looking-sounding operations while maintaining safe control. There would also be using iThing-Apps to add higher levels of sophistication to the train operations and operations-programs (something similar to using JMRI). The control-variables can be changed as part of the operations-program opening the door for such things as a DBTC-Locomotive having an obvious malfunction. Using Bluetooth over DCC for command and control opens up many unseen possibilities. 

I am thinking that most people would have fun trying to successfully (manually) run one or two DBTC-Locomotives while several “automated” DBTC-Locomotives were also running their operations-program.

All the kids that have run on my layout are a lot more interested in DCC than DC. They look at locomotive control with a DC-system as prehistoric and quickly lose interest.
Bob


----------



## gregc

RT_Coker said:


> There would also be using iThing-Apps to add higher levels of sophistication to the train operations and operations-programs (something similar to using JMRI). The control-variables can be changed as part of the operations-program opening the door for such things as a DBTC-Locomotive having an obvious malfunction. Using Bluetooth over DCC for command and control opens up many unseen possibilities.


i think this level of automation and better could easily be achieved using existing components and centralized control (PC). I certainly believe a centralized approach would be simpler than a distributed approach and should be able to support multiple trains interfering with one another

By centralized control, I mean a device that can use C/MRI approaches to detect block occupancy and turnout positions and control turnout positions, signals and via DCC locomotives. Recognizing block occupancy is of course key to being able to stop/slow trains and turnouts to move a train across a route.

bluetooth or wireless is not necessary for this type of automation but I understand that two-way communication is needed by the controller if it is in the locomotive in the DBTC.

I don't see "unseen possibilities" that aren't easier to implement with centralize control.

I think centralized control (an old PC/laptop) would be less expensive than putting more expensive controllers into many locomotives. Perhaps all that's needed is a high end Arduino or Raspberry PI (900 MHz ARM, 1 GB RAM) under the benchwork.

and there's always the possibility of putting the centralized control PC in a closet and accessing it remotely through an iPad, iPhone or remote laptops, either with hardwire, wifi or bluetooth.


----------



## RT_Coker

gregc said:


> i think this level of automation and better could easily be achieved using existing components and centralized control (PC). I certainly believe a centralized approach would be simpler than a distributed approach and should be able to support multiple trains interfering with one another
> 
> By centralized control, I mean a device that can use C/MRI approaches to detect block occupancy and turnout positions and control turnout positions, signals and via DCC locomotives. Recognizing block occupancy is of course key to being able to stop/slow trains and turnouts to move a train across a route.
> 
> bluetooth or wireless is not necessary for this type of automation but I understand that two-way communication is needed by the controller if it is in the locomotive in the DBTC.
> 
> I don't see "unseen possibilities" that aren't easier to implement with centralize control.
> 
> I think centralized control (an old PC/laptop) would be less expensive than putting more expensive controllers into many locomotives. Perhaps all that's needed is a high end Arduino or Raspberry PI (900 MHz ARM, 1 GB RAM) under the benchwork.
> 
> and there's always the possibility of putting the centralized control PC in a closet and accessing it remotely through an iPad, iPhone or remote laptops, either with hardwire, wifi or bluetooth.


Greg,
I guess it is safe to say that we have significantly different visions of the future of the hobby, and it is not likely that either of us are going to change his mind anytime soon.
Bob


----------



## gregc

RT_Coker said:


> Using Bluetooth over DCC for command and control opens up many unseen possibilities.


you've alluded to advantages of a superior approach that I don't understand. I'm asking for more information and suggesting alternate approaches for comparison.


----------



## RT_Coker

gregc said:


> you've alluded to advantages of a superior approach that I don't understand. I'm asking for more information and suggesting alternate approaches for comparison.


Greg,
Beyond the advantages of real-two-way-signals, much-increased-signal-bandwidth, reliability, plug-and-play-capability, non-conductive-tracks (battery-power-locomotives), and so on that Bluetooth (or any other good wireless technology) provides over DCC:

The estimated delta-cost of DBTC-decoder-boards over DCC-decoder-boards are insignificant (maximum of $10) when compared to locomotive-cost.

I already have the development kit for inexpensive Bluetooth-units (as in DBTC-Accessory-Controllers) that can relay Bluetooth signals (no ~100ft range limit).

The extra hardware for adding locomotive-sounds is as little as $8 and much more flexible than having the sounds originate in the DCC-sound-decoders. Info here: http://www.ebay.com/itm/Smallest-Po...hash=item1c540a4c5b:m:mU0Jh0R3MXZ1xBaB_PvSqQA

Unknown others.
Bob


----------



## gunrunnerjohn

I've tinkered with three different BT speaker sets, and none of them have given me the range I'd need for any decent sized O-scale layout. I tried driving them from a PC, laptop, the iPad, and my Android phone. The experienced dropouts as close as 15 feet when moving, not nearly enough range to seriously consider them. Not sure what to do with all the experimental equipment, but I'm not sold on using BT to send the audio to my trains yet.


----------



## RT_Coker

gunrunnerjohn said:


> I've tinkered with three different BT speaker sets, and none of them have given me the range I'd need for any decent sized O-scale layout. I tried driving them from a PC, laptop, the iPad, and my Android phone. The experienced dropouts as close as 15 feet when moving, not nearly enough range to seriously consider them. Not sure what to do with all the experimental equipment, but I'm not sold on using BT to send the audio to my trains yet.


John,
I just ran a test of the X3 Bluetooth speaker (on a flat-car next to the locomotive) on my mid-size HO layout. I got good sound (with no drop outs) from up to ~60 ft with the X3 inside a tunnel (polyurethane). The locomotive is my “test” locomotive (the poorest running one). However when the locomotive was run at maximum speed, you could hear drop outs at ~60ft inside the tunnel. I suspect that the Bluetooth-Sound-coding is not as robust as the Bluetooth-Serial-coding and therefore more susceptible to RF-interference (most likely from the motor being control by PWM). 

Based on my limited test, I would not recommend the current Bluetooth-Sound-coding for use on large-layouts, in-or-next-to-locomotives-with-significant-RF-noise, or in-an-environment-that-could-have-significant-RF-noise (club, show, ...).
Bob


----------



## gunrunnerjohn

If you're talking about this one, that's one that I tested, it wasn't impressive.


----------



## RT_Coker

gunrunnerjohn said:


> If you're talking about this one, that's one that I tested, it wasn't impressive.
> 
> View attachment 137522


That's it.
Bob


----------



## gregc

RT_Coker said:


> Beyond the advantages of real-two-way-signals, much-increased-signal-bandwidth, reliability, plug-and-play-capability, non-conductive-tracks (battery-power-locomotives), and so on that Bluetooth (or any other good wireless technology) provides over DCC:


bob,
thoughtful constructive criticism and discussion are part of the successful engineering process.

it sounds like your "vision of the future of the hobby" is to have not just wireless, but bluetooth two-way communication with all control elements of the layout (i.e. locomotive, turnouts, occupancy detectors). You've suggested that an intelligence to control the layout reside within the locomotive(s) and at least partially "automated" behavior to be programmable thru that intelligence.

while this approach (intelligence within the locomotive) requires two-way reliable communication, I believe it is a more complicated (i.e. distributed) and expensive approach than already exists (i.e centralize control) today if the vision is semi-autonomous behavior. 

The Pacific Southern uses Bruce Chubb's C/MRI techniques and custom software for layout monitoring and control and DCC for locomotive operation. It is not automated. It's intelligence resides in the dispatcher, tower operations and engineers operating the trains. (But the dispatcher PC would have all the information needed including DCC control to support automated control you suggest).

And if I understand your vision correctly, you're suggesting that accessories (e.g. turnout control, occupancy detectors) also be wireless to be accessible to the intelligence within the locomotive. (if i'm wrong, help me understand). I believe this is an unnecessary expense.

Is the primary focus of “Open-Source-Bluetooth-Train-Control”, inexpensive bluetooth communication or semi-autonomous train control to "attract new and younger hobbyists"?


----------



## RT_Coker

gregc said:


> bob,
> thoughtful constructive criticism and discussion are part of the successful engineering process.
> 
> it sounds like your "vision of the future of the hobby" is to have not just wireless, but bluetooth two-way communication with all control elements of the layout (i.e. locomotive, turnouts, occupancy detectors). You've suggested that an intelligence to control the layout reside within the locomotive(s) and at least partially "automated" behavior to be programmable thru that intelligence.
> 
> while this approach (intelligence within the locomotive) requires two-way reliable communication, I believe it is a more complicated (i.e. distributed) and expensive approach than already exists (i.e centralize control) today if the vision is semi-autonomous behavior.
> 
> The Pacific Southern uses Bruce Chubb's C/MRI techniques and custom software for layout monitoring and control and DCC for locomotive operation. It is not automated. It's intelligence resides in the dispatcher, tower operations and engineers operating the trains. (But the dispatcher PC would have all the information needed including DCC control to support automated control you suggest).
> 
> And if I understand your vision correctly, you're suggesting that accessories (e.g. turnout control, occupancy detectors) also be wireless to be accessible to the intelligence within the locomotive. (if i'm wrong, help me understand). I believe this is an unnecessary expense.
> 
> Is the primary focus of “Open-Source-Bluetooth-Train-Control”, inexpensive bluetooth communication or semi-autonomous train control to "attract new and younger hobbyists"?


Greg,
“Open-Source-Bluetooth-Train-Control” does not need “occupancy detectors” for its “automated” operations. However, they could be added to the DBTC-Accessory-Controllers. One of the main long-term objectives of “Open-Source-Bluetooth-Train-Control” is to greatly simplify layout wiring (including “track-wiring”). Yes that means battery-power-locomotives and tracks without power or control-signals.

By American standards I am a very frugal individual, but I would gladly pay the extra $10 each to have DBTC in my locomotives and the ~$100 (initial DBTC board cost) each for the hardware to convert 5 or 6 of my existing DCC locomotives. They is a long list of the advantage of just DBTC over DCC in the locomotives already in the related threads. The first DBTC-Accessory-Controllers would be few and control many accessories, but (because of the low incremental cost of Bluetooth) would eventually become an existing part of the individual accessories and enable a “plug-&-play” capability.

I think we are comparing “apples to oranges”, that is “an-extension-of-existing-concepts” to a “new-concept”. Not a very far comparison for either one.
Bob


----------



## jprampolla

Hi Folks,

I use this speaker:
http://www.walmart.com/ip/i.Sound-PopDrop-Mini-Bluetooth-Speaker-Licorice/39364365








in a little homemade shorty gondola:








and I haven't had any drop-out issues on my layout which is in a 30' by 24' space.
I think the speaker is only part of the equation. The transmitter has to be good also.
I am using a cheap tablet that is about 10 months old:
http://www.walmart.com/ip/Nextbook-7-Tablet-16GB-Quad-Core/38334381









My layout is "L" shaped, 22' by 16' in a 720 sq ft space.

Take care, Joe.


----------



## gunrunnerjohn

I have that exact speaker as well, once the train goes around out of sight about 20' away, it drops out.

I think I'll stick with on-board sound generation.


----------



## jprampolla

gunrunnerjohn said:


> I have that exact speaker as well, once the train goes around out of sight about 20' away, it drops out.
> 
> I think I'll stick with on-board sound generation.


Hi John,

Perhaps there are other issues with interference in your train room.

Take care, Joe.


----------



## gunrunnerjohn

Quite possible, but then that would be a environmental restriction that could easily affect many other people. The technology should be able to work around this if it's to be universally acceptable.


----------



## jprampolla

gunrunnerjohn said:


> Quite possible, but then that would be a environmental restriction that could easily affect many other people. The technology should be able to work around this if it's to be universally acceptable.


Hi John,

I suspect the issue may be unique to your situation. Perhaps it doesn't play nice with the Lionel equipment.


Take care, Joe


----------



## gunrunnerjohn

Yep, that makes in universal.


----------



## jprampolla

gunrunnerjohn said:


> Yep, that makes in universal.


Hi John,

No! Not everyone has Lionel peripherals, but we'll see if Bluetooth catches on or not.



Take care, Joe.

Edit:

O.K. I see what you are saying. It might exclude those few running things that might interfere. J.

P.S. My cheap tablet has Bluetooth v4.0, and that might be the reason why I have a better experience with the Bluetooth speaker than John's situation. J.


----------



## RT_Coker

*Open-Source DBTC Update*

I am still working on a getting a demonstration-DBTC-locomotive running and a video of its “automated” operation. I have one ready for the drive-shafts (the dire-shafts are removed for static testing). As this is the only DBTC-locomotive, I will be getting the HO-FTA put together (as a DBTC-locomotive) for backup first.

I am doing extensive static testing on the firmware in the demonstration-DBTC-locomotive. The precision-scale-distance and motor-speed control are working like a dream (good bye to DCC-CVs used for BEFM, speed matching & ...).

I changed the firmware so that DBTC-CVs can be changed as part of the “automated” operation. This will make it possible to do many things, like have a diesel locomotive move at one “momentum” to pick a heavy load of cars, and then switch to a slower “momentum” once the heavy load is coupled up. 
Bob


----------



## gregc

RT_Coker said:


> The precision-scale-distance and motor-speed control are working like a dream (good bye to DCC-CVs used for BEFM, speed matching & ...).


would you be willing to describe the algorithm for doing this?

doesn't something like need to know wheel diameter, gearing and motor behavior (rpm/voltage) under various loads?

is there a calibration step?


----------



## RT_Coker

gregc said:


> would you be willing to describe the algorithm for doing this?
> 
> doesn't something like need to know wheel diameter, gearing and motor behavior (rpm/voltage) under various loads?
> 
> is there a calibration step?


Greg,
I am using an IR sensor and a circular-tachometer-wheel to measure motor-rotation (currently 6 pulses per motor revolution) in a processor-counter. I do a (one time per locomotive type) scale-distance-calibration on a measured section of track. The distance measurement is then in scale-feet. A processor timer-interrupt occurs at a set time interval (~7 times a second). This timer-interrupt calculates the delta-distance from the processor-counter. Current-speed equals delta-distance divided by delta-time.

The motor drive (10-bit-PWM) is constantly (~7 times a second) adjusted according to the difference between desired-motor-speed and current-motor-speed. Because realistically operated locomotives are not “race cars”, I am not using any complex feedback algorithms to control motor speed. If such algorithms are not very carefully implemented then the train speed can start oscillating with the coupler-slack alternately compressing and expanding.
Bob


----------



## gregc

RT_Coker said:


> I am using an IR sensor and a circular-tachometer-wheel to measure motor-rotation (currently 6 pulses per motor revolution) in a processor-counter.


that certainly makes things very easy. A bit more than just adding a decoder though


----------



## jprampolla

Hi Bob,

Do you think BlueRail intends to use Back EMF for speed control? I was trying to get some information on the Picaxe with BEMF, but it seems much too difficult. 

Take care, Joe.


----------



## jprampolla

Hi again, Bob,

Instead of putting this in a post script and it getting lost, here is a thread on the Picaxe forum that might interest you (regarding BEMF):

http://www.picaxeforum.co.uk/showthread.php?27399-Success-with-Back-EMF-implementation

Take care, Joe.


----------



## RT_Coker

Joe,
Thanks for the information!

Greg & Joe,
I already have BEMF sampling in the firmware and the hardware design. [The BEMF sampling is done by interrupt and occurs only in the off cycle of the PWM.] I plan on implementing and optimizing the BEMF control logic in the tachometer-locomotive after it has been track tested. The tachometer (and some special test code in the firmware) will allow excellent measurement of the BEMF performance in real test conditions. Hopefully this will produce a stable BEFM implementation under varying realistic conditions (for those that don’t have or want to add a tachometer).
Bob


----------



## RT_Coker

*DBTC_Loco_FW_Demo_01*

First video of the first OS-DBTC locomotive is here: https://www.youtube.com/watch?v=dlr2XM-8TI0&feature=youtu.be

Don’t get distracted by the hardware (just a kludge for now). HO production hardware is just a little larger than the HC05-Bluetooth-sub-board.

The Command-Stack (CS) being executed by the loco demonstrates the precision-scale-distance-control and is as follows:
1)	Proceed-To-Time = 5 seconds. [For time to start recording.]
2)	Proceed-T0-Distance = 3 scale-feet.
3)	Max_Speed = 40 ~MPH.
4)	Proceed-To-Time = 3 second. [For time break between movements.]
5)	Proceed-T0-Distance = 6 scale-feet.
6)	Max_Speed = 40 ~MPH.
7)	Proceed-To-Time = 3 second. [For time break between movements.]
8)	Proceed-T0-Distance = 12 scale-feet.
9)	Max_Speed = 40 ~MPH.
10)	Proceed-To-Time = 3 second. [For time break between movements.]
11)	Proceed-T0-Distance = 24 scale-feet.
12)	Max_Speed = 40 ~MPH.
13)	Proceed-To-Time = 3 second. [For time break between movements.]
14)	Proceed-T0-Distance = 48 scale-feet.
15)	Max_Speed = 40 ~MPH.
16)	Proceed-To-Time = 3 second. [For time break between movements.]
17)	Proceed-T0-Distance = 96 scale-feet.
18)	Max_Speed = 40 ~MPH.
19)	Proceed-To-Time = 3 second. [For time break between movements.]
20)	Proceed-T0-Distance = 192 scale-feet.
21)	Max_Speed = 40 ~MPH.

This is the first of hopefully many CS test-files that make testing OS-DBTC-locomotives a much more reliable and repeatable process.

Minimum motor-speed is set to 3 ~MPH in CVs. Motor-speed-control is within +- 0.67 ~MPH. This is the limitation of the six ticks-per-motor-revolution tachometer-wheel in this HO locomotive. The firmware limitation is +-1/8 ~MPH. [I have not determined the upper limit on the ticks-per-motor-revolution for HO tachometer-wheels.]

The control-variables (CV’s) that set the scale-feet-per-motor-tick could be off by as much as +-03%.
Bob


----------



## DonR

Bob

The video link responds with 'This video is private'. Do you need to set
a control at Youtube?

Don


----------



## RT_Coker

DonR said:


> Bob
> 
> The video link responds with 'This video is private'. Do you need to set
> a control at Youtube?
> 
> Don


Thank you Don,
Video is obviously not one of my things.
Bb
o


----------



## gunrunnerjohn

It it the video or does it oscillate at low speeds? I see that effect in videos at times, so I didn't know if it was actually doing that or it was the video.

FWIW, most of the O-gauge tach strips are around 24 stripes, which would help with low speed control. Lionel Legacy has even more pulses for a rev, probably why it's low speed performance is very good.


----------



## RT_Coker

John,
Yes, the loco oscillates at low speed 3 ~MPH. At this speed I am only getting ~2 ticks per speed sample. Also, I have not tried to optimize the CV settings that effect low speed yet. This (bought used & broken) loco is about at the end of its useful life. Especially after all the modifications and my miss-steps over the last 2 years.

This oscillation is another reason for already having BEMF-sampling in the F/W. It may also be needed to smooth low speed operation for HO and will probably be a must for smaller scales someday.
Bob


----------



## gunrunnerjohn

That's the benefit of more samples from the tach I suspect. With two clicks, I can see why the speed control doesn't quite know what to do. I'm guessing you need at least three or four times that many. MTH DCS with 24 pulses/rev has issues with low speed performance as well.


----------



## RT_Coker

*Precision-Scale-Distance-Control*

John,
The current tach-wheel design is based on getting precision-scale-distance-control in HO (currently ~4 ticks-per-foot). The current tach-wheel is a reasonable conservative approach that allows for the current (simple and inexpensive) tach-sensor. Precision-motor-speed control by tach will always take second place to precision-scale-distance-control for me. From what I have seen, properly done BEFM can provide any needed secondary speed control. 

Reliably precision-scale-distance-control in the locomotive is the key to inexpensive automated and independent layout operation.
Bob


----------



## RT_Coker

All,
To my knowledge this is the first hobby-loco to use precision-scale-distance-control and to autonomously-execute-internal-operational-commands. And from my point of view it looks like it will be the last for some time. 

I any very thankful that the (much abused) first-OS_DBTC loco ran on the test-track long enough to get some tack-testing and at least one video. I want bore you with all the original-loco-hardware that is no longer working on this loco. It served me well for ~2 years of experimenting! It will now have to be retired to static-testing for the rest of its life.

I plan on “moth-balling” this project by the end of this month, and leaving it “moth-balled” until (and if) OS-DBTC-decoder-hardware becomes available for further track-testing (assuming that I am still functioning on this earth by then). Two years of trying to swim (mostly on my own) against the existing “strong-electronic-currents” in the hobby is enough.

*** Much thanks to those that helped!!! ***
Bob


----------



## RT_Coker

The OS-DBTC-decoder-boards will have an auto-run-on-power-up feature. (It is in the firmware and tested.) This is intended to be used for things like trolleys (or any single-power-unit on its own track). So all that is needed after the operational-commands are set up with an iThing-App, is a ~12 volts DC wall-wart (or battery-power), and a magnet in (or near) a strategic location on the track. Set the powered-unit near the starting point and turn the power on. The operational-commands provide for much more that just stops, waits, accelerations, and decelerations. Only one “sensor” (a magnet), and the number of stops, waits,... are no longer limited by hardware, or require the addition or moving of sensors.
Bob


----------



## RT_Coker

All,
Two OS-DBTC documents (updated) “BlueTrain IF Manual.rtf” and (new) “BlueTrain PIC Dev HW.rtf” are available to *anybody *for download at: https://sourceforge.net/projects/dbtc/files/BlueTrain/.

The “HW” document is intended for use as an input into the design/development of OS-DBTC-mobile-decoder-boards. The processor could also be a PIC18F46K22, and the DRV8801-chip could be a full-wave-PWM-motor-circuit. Most of the simple PIC I/O can be move to different PIC-pins to minimize the board size. The HC05-Bluetooth-sub-board would typically be mounted on the non-component side of the decoder-board with the Bluetooth-antenna protruding over the edge.
Bob


----------



## gunrunnerjohn

I looked, but I didn't see the actual code you were working on.


----------



## RT_Coker

John,
Code, ... is not available at least until I can test on “real” H/W. I am the only one that has code,...

It is the only real leverage I have to get H/W that runs open-source F/W.
Bob


----------



## RT_Coker

If anybody is looking for something that shows that the code is real, look around here: https://spaces.atmel.com/gf/project/bluetrain/frs/?action=FrsReleaseView&release_id=413.
This is old atmega328p code that ran in the first (USB-connected) O-S-DBTC locomotive. 
Bob


----------



## RT_Coker

Link to video of X1-Bluetooth-speaker being tested here: https://www.youtube.com/watch?v=qpj_b4OUXNA.

Sound test of X1-Bluetooth-speaker on HO-layout at ~60 feet. Some sound-breakup at max-distance in tunnel for locomotive at max-speed.
Bob


----------



## Shdwdrgn

I'd be interested in the code just to see what pitfalls you've managed to fix or avoid. Since I'm doing something fairly similar with WIFI instead of bluetooth, I imagine I'll run into many of the same problem along the way. If/when you do release the code, please be sure to post an announcement in this thread?

Of course I'm probably at least a couple years away from having even a slightly operational layout, so I have time to wait...


----------



## RT_Coker

All,
The BlueTrain PIC18 bootloader has been released as a complete “MPLABXProjects”in a “Compressed (zipped) Folder (.zip)” called “PIC18_Bootloader.X”.

The BlueCMD control application for BlueTrain has been released as a complete MS-Visual-C-6.? Project in a “Compressed (zipped) Folder (.zip)” called “BlueCMD”.

Files at: https://sourceforge.net/projects/dbtc/files/BlueTrain/.

BlueTrain PIC18 code, will not available at least until I can test on “real” H/W. I am the only one that has code,... It is the only real leverage I have to get H/W that runs open-source F/W.

Bob


----------



## RT_Coker

*This project has been “moth-balled”!*

This project has been “moth-balled” (most likely permanently)! It is being replaced by a new 2nd generation OS-DBTC project here: http://www.trainboard.com/highball/...2nd-generation-open-source-dbtc-thread.91501/.

*OS-DBTC* The 2nd Generation Open-Source-DBTC Thread

Bob


----------



## gunrunnerjohn

That doesn't bode well for the future of this project, here's what I see over there...


----------



## RT_Coker

John,
Thanks! I fixed it.
Bob


----------



## RT_Coker

Looks like I might have found an off-the-shelf board for HO-scale open-source DBTC (Romeo BLE Mini Microcontroller). Board information here: https://www.dfrobot.com/wiki/index.php/Romeo_BLE_mini_SKU:DFR0351.

I pick up 2 boards for ~$30 each on eBay, and I am considering porting my PIC18 C code back to the Atmega328P.
Bob


----------



## RT_Coker

Got the DFR-Dongle in and it works for me. I am able to wirelessly download and control the DFR0351 board form the Arduino IDE. This means that I can proceed with my BlueTrain OS-DBTC firmware transition for a PIC to the Atmega328p on the DRF0351 board using Atmel Studio.

However, my initial effort to wirelessly connect and control the DRF0351 from an android-tablet was not successful. I will keep working this issue, because eventually my win32-BlueCmd program should be ported to an App for Bluetooth-iThings. This may take awhile for this App development is new to me and will be only a sideline as necessary to my BlueTrain OS-DBTC work. My Interface Manual and BlueCmd package can be downloaded here: https://sourceforge.net/projects/dbtc/files/BlueTrain/

Bob

LINKS for those that are interested or just want to play with an OS-DBTC setup of their own:

Initial Reference: https://www.dfrobot.com/wiki/index.php/Romeo_BLE_mini_SKU:DFR0351

Free Arduino IDE here: https://www.arduino.cc/en/Main/Software

DFR0351 on eBay here: http://www.ebay.com/itm/Romeo-BLE-M...687722?hash=item1a1e9bf7ea:g:qI4AAOSwnbZYEOKG

DFR-Dongle on eBay here: http://www.ebay.com/itm/182114342135?_trksid=p2060353.m2749.l2649&ssPageName=STRK:MEBIDX:IT

If related threads titles start with “*OS-DBTC* “ (on this and other forums), they will be easier to find and follow (just a suggestion).


----------



## RT_Coker

*** The OS-DBTC baseline is now complete!!! ***

The door is now open for the development of Open-Source-Direct-Bluetooth-Train-Control.
The DFR0351 board is being controlled by the “Bluno Basic Demo” App on my android phone. The problem was my “?good deal?” Android tablet! I should not have assumed that it had bluetooth-4.x just because it had android 4.x.x. 

I will be working on the BlueTrain F/W for the DFR0351 board. 

And looking for somebody(s) that can/will do the initial BlueCmd Android App(s).

It should also be possible for you H/W types to turn the DFR03151 board into a plug replaceable unit for DCC decoders.
Bob


----------



## RT_Coker

Here is the preliminary OS-DBTC-BlueTrain design information:
The H/W-F/W design is to my requirements for “smart” locomotives, and to also support a “DCC-Decoder-Plug” version of the H/W (without the DFR0351 connector components and with an added DCC-to-~10V-power H/W).

The DFR0351 board’s PWM-outputs appear to be crossed to me!
1)	DFR0351 Notes:
a)	T0-PWM-Uncrossed (T0-PWM Crossed with T2-PWM?):
i)	OC0A -> PD6 -> D6 -> BIN2 -> BOUT2 -> MB2
ii)	OC0B -> PD5 -> D5 -> AIN2 -> AOUT2 -> MA2
b)	T2-PWM-Uncrossed (T0-PWM Crossed with T2-PWM?):
i)	OC2A -> PB1 -> D9 -> BIN1 -> BOUT1 -> MB1
ii)	OC2B -> PD3 -> D3 -> AIN1 -> AOUT1 -> MA1
c)	T1-Input on PD5 is wired as output and not available for Tach-In!

Atmga328P Resources used:
1)	T0-8-bit is Motor-Count (Tack-In-> Green-4-PD4) {No PWM on PD6-PD5 }:
2)	T1-16-bit is RTC:
3)	T2-8-bit is Motor-PWM (PD3-PB1) (MA1-MB1?):
4)	PD5 & PD6 are F4 & F5 (MA2? & MB2?) Discrete-Gnd-Outputs (~1A-Pluse – Coupler-Release or …):
5)	PB2 thru PB5 are F0 thru F3 (Green-10 thru Green-13) Discrete-Gnd-Outputs (20mA – Lights or …):
6)	PD2 (INT0-interrupt, highest-priority) is Mark-In (Green-2): 
7)	Future TWI (IC2) I/F?:
Bob


----------



## RT_Coker

I have been making good progress.
The DFR0351 board design necessitated some more BlueTrain design changes. The motor connection has been changed to MA1 & MB1. And timers 1 & 2 are now used to get the motor PWM. This just makes the motor PWM setup more complex than it would need to be with a better board design.
Also the DFR0351’s Atmega328p-to-BLE-USB connection had to be changed from 115200 to 57600 baud. The Atmega IDE gave a warning message that 115200 baud was not within tolerance and I could not get a forced manual setup of 115200 baud to work. Still fast enough to shame any connection using a track-signal-path.
Bob


----------



## RT_Coker

The BlueTrain3-Test-Breadboard is complete with an Adriano Sketch that tests/demonstrates the DRF0351 as a DBTC-control-board. The motor and tachometer are from the old (and worn out)) BlueTran1 & 2.

There is (1.5 amp) + - Motor-Control, 4 (20 ma ground) light type outputs (F0, F1, F2, & F3) and 2 ~1.5 amp Motor-Voltage outputs (F4 or F5) {both will not provide voltage at the same time}. There is also a (future F/W upgrade) Back-EMF input, Tachometer input, Mark-Interrupt input, and (future F/W upgrade) IC2 interface. F0 (normally front-loco-light) is also feed by the Atmega328p-SCK signal. So the F0-light will show boot-up, F/W download, and connection activity of the DRF0351 board.

I also have the DRF0267 and motor-shield boards for a Bluetooth-version of DCC++ (BTDCC++). I have future plans on using BTDCC++ to control a DCC-turnout(s) by command(s) from the execution-stack in BlueTrain3. This would allow a demonstration of BlueTrain3 autonomous automation capabilities. I have keep enough track for a simple oval with one DCC-turnout siding. I plan on putting this track on a board that can be titled up and down so that I can test/debug/verify the tachometer and future Bemf motor control under normal to extreme conditions.
Bob


----------



## RT_Coker

The BlueTrain3-Test-Locomotive is complete. The locomotive part is an analog-Bachmann-FTB with an added tachometer-wheel on the motor-shaft, IR-source/detector with mounting-bracket, and a magnetic-reed-switch on the bottom. The DRF0351 I/O used is +-motor-control-output, F0-frount-light-ground-output, tachometer-tick-input, 5-volt-mark-interrupt-input, and 5-volt-power. The back-emf-circuit will be added to the DRF0351 board after testing of the tachometer-motor-speed-control in the firmware. (No need for a separate loco speed measuring system!)

Now that Christmas is complete and the grandkids are back in school, it is time to get to the intense work of porting the firmware from a PIC18 target to the atmega328p of the DFR0351. The titling-test-track will also be completed with the firmware porting, and will provide breaks from the occasional frustrations of firmware development.

I also install and check out Android Studio for development of a BlueCmd App for Android iThings, and bough a cheap Andriod-10”-tablet that supports Bluetooth-4.0. The “BlunoBasic Demo” app on the tablet runs the BlueTrain3-Test-Locomotive with my Adriano-Studio-DFR0351-demo-stetch.
Bob


----------



## wvgca

"added tachometer-wheel on the motor-shaft, IR-source/detector with mounting-bracket, and a magnetic-reed-switch on the bottom"

just curious as to why both IR and reed?


----------



## RT_Coker

wvgca said:


> "added tachometer-wheel on the motor-shaft, IR-source/detector with mounting-bracket, and a magnetic-reed-switch on the bottom"
> 
> just curious as to why both IR and reed?


The “IR-source/detector” is the tachometer (distance/speed control) and the “magnetic-reed-switch on the bottom" detects track-magnets for precision-stops at known-track-location(s). The precision-distance-control needs to be occasionally referenced to a known-track-location (removing the buildup of distance-errors).
Bob


----------



## wvgca

okay, makes sense .. wonder if it would error trip for those who use between track magnets for uncoupling?


----------



## RT_Coker

wvgca said:


> okay, makes sense .. wonder if it would error trip for those who use between track magnets for uncoupling?


Basically yes the hardware is designed to trip on these magnets; but the locomotive only stops when it is told to look for the “trip” by command.
Bob


----------



## wvgca

RT_Coker said:


> Basically yes the hardware is designed to trip on these magnets; but the locomotive only stops when it is told to look for the “trip” by command.
> Bob



The reason that I asked was that I "assume" fixed distance / interval magnet trips would be required for a consistent reference distance ...for IR sensor calibration ??
And in my case, there is no consistent fixed distance between magnet arrays


----------



## RT_Coker

wvgca said:


> The reason that I asked was that I "assume" fixed distance / interval magnet trips would be required for a consistent reference distance ...for IR sensor calibration ??
> And in my case, there is no consistent fixed distance between magnet arrays


The magnet-trips are not for calibration. The IR-sensor puts out a fixed number of pulses per motor-revolution, and the pulses increment an atmega328p counter that keeps track of distance in terms of motor-tachometer-count. The only calibration needed is a one-time-per-locomotive-type of the motor-count-per-scale-foot (that is setup in the control-variables). This calibration is done on a known-length-of-straight-track.

The details are in the interface document.
Bob


----------



## wvgca

I get it now...
Thanks for clarifying my incorrect assumption ...

Happy New Year..


----------



## RT_Coker

I started porting the firmware today. In trying to find a design using the DFR0351 board to control the motor and also leave a usable counter/input for the tachometer, I managed to confuse myself into thinking I had a workable solution. What I have is a working DBTC solution without a working tachometer counter/input (a “dumb” DBTC-locomotive solution). The only possible solution that I see is to tack a wire on the DFR0351’s DRV8833PWR-pin-15 to get a T1-counter-input; something that is beyond my hardware capabilities. Apparently I have put in a lot of work and expense only to encounter another hardware-dead-end.
Bob


----------



## wvgca

from what I gather the DFR0351 has 8 digital and 4 analog pins.. 
I didn't see anything in the pdf as for pins used for functions, but could you put the coupler openings on one rather than two??
No idea if I'm totally off base or not?


----------



## RT_Coker

wvgca said:


> from what I gather the DFR0351 has 8 digital and 4 analog pins..
> I didn't see anything in the pdf as for pins used for functions, but could you put the coupler openings on one rather than two??
> No idea if I'm totally off base or not?


I am not yet using any outputs for couplers. It is a problem with the way the atmega328p-PWM-outputs are connected to the DRV8833-motor-drive-inputs. Normally the two PWM-outputs of an individual timer would be connected to provide one bidirectional-motor-control. But for some reason (according to the schematic) the DFR0351 is connected as follows:
1)	T0-PWM:
a)	OC0A -> PD6 -> D6 -> BIN2 -> BOUT2 -> MB2
b)	OC0B -> PD5 -> D5 -> AIN2 -> AOUT2 -> MA2
2)	T1-PWM:
a)	OC1A -> PB1 -> D9 -> BIN1 -> BOUT1 -> MB1
b)	OC1B -> PB2 -> D10
3)	T2-PWM:
a)	OC2A -> PB3 -> D11
b)	OC2B -> PD3 -> D3 -> AIN1 -> AOUT1 -> MA1
T0 is the only timer that has an available input, so it has to be used for the tachometer-input. This leaves two available PWM-outputs that control the same side of two different motor-drive-circuits. There may be a way to get these two PWM-outputs (MA1 & MB1) to provide bidirectional-motor-control; but I have not been able to find it.

I got ahead of myself and already have 4 DFR0351’s, so I will probably give the “wire-tack” approach to making the T1-input available a try.
Bob


----------



## RT_Coker

Looks like BlueRail Train’s US patent application “WIRELESS MODEL RAILROAD CONTROL SYSTEM” has been rejected with a “Status: Final Rejection Mailed” and “Status Date: 07-01-2016”.
Bob


----------



## gunrunnerjohn

Wow Bob, I didn't expect to hear that!


----------



## RT_Coker

gunrunnerjohn said:


> Wow Bob, I didn't expect to hear that!


Yes; looks like the US patent office did something right this time.
Bob


----------



## RT_Coker

Looks like my “hardware-dead-end” has moved OS-DBTC to a much better hardware design. The new design uses a DFRobot Bluno Beetle (DFR0339) board and a Pololu DRV8801 motor driver board and battery power. Unless I have missed something important (once more) the functionally match between the DFR0339 and DRV8801 is nearly perfect for OS-DBTC. This design is also something that is not beyond my hardware capabilities, and provides a smaller and more flexible footprint that is a much better potential fit for HO locomotives.
Bob


----------



## gunrunnerjohn

Yep, in the past it seems that you could patent a shadow.


----------



## gunrunnerjohn

Bob, I added a version of the file in PDF form so that more people can read it.

BTW, you do know that there is already a product called BlueTrain, right? http://bluetrain.android.informer.com/


----------



## RT_Coker

gunrunnerjohn said:


> Bob, I added a version of the file in PDF form so that more people can read it.
> 
> BTW, you do know that there is already a product called BlueTrain, right? http://bluetrain.android.informer.com/


Thanks!!!
My apologies to “Bob Krivacic”. As soon as I get this new design up and running, I will try and contact Bob and see if he is interested in doing the “BlueCmd” App for OS-DBTC.
Bob


----------



## RT_Coker

I finished porting (complied and code-reviewed) the firmware code for the atmega328p as implemented on the Bluno Beetle board. Now the wait is for the Beetle boards to arrive from oversees (~1 week). As an American, I sure would like to be buying and using American hardware! The BlueTrain3-Test-Breadboard will be reworked for the new hardware design, and then the firmware testing/debugging will start. The BlueTrain3-Test-Locomotive will also be reworked for the new hardware design.

I am looking on eBay for HO locomotives that will be good candidates for the interior installation of the hardware. My take on the criteria is: HO, non-DCC, accessible fly-wheel for adding the tachometer-sensor, and plenty of available interior space (for my not-so-good hands and eye sight). I will probably be adding a circuit to provide power from the track in place of the battery (already have the necessary hardware from BlueTrain1). *Locomotive recommendations?* I picked up a very nice 8-40 locomotive, but it is of the old design (split-frame un-isolated motor), and would take a lot of frame cutting/grinding to make room for the hardware. It is defiantly not a good first candidate.
Bob


----------



## RT_Coker

The OS-DBTC test track is completed. The picture shows it at a ~4% grade with the pictured saw-horse being ~2 inches higher that the other one. I ran some tests with no speed control (tachometer or Bemf) so I would have “before” reference. The weighted (~6 extra ounces) gondola was doing a good herky-jerky-coupler-slack dance on the downgrade.
Bob


----------



## RT_Coker

I made a second attempt to wire the BlueTrain test locomotive. It didn’t survive my not-so-good-eyes and shaky-hands. It functions but without any motor-drive. So after I mope around for awhile and eventually re-motivate myself, I hope to get back to working on the BlueTrain steam locomotive. I hope than having more room for the hardware and using a lot of connectors in the steam locomotive will compensate for my hardware limitations. So it may be months before there are any more of my posts to this thread.
Here are some pictures.
Bob


----------



## gunrunnerjohn

Bummer, I think motor drive would be key to success here.


----------



## Shdwdrgn

Be careful with using too many connectors... Remember they'll corrode over time, and for low-level signals like you get from sensors, that could really degrade their reliability.

I feel for ya with the hand shakes. I'm starting to get tremors when I try to hold a piece for a few minutes, makes it real hard to do fine trimming and filing on pieces. Hasn't affected my soldering yet, but it's only a matter of time...


----------



## Lemonhawk

I had a solar collector system used to heat the house when I lived in Minnesota. Had about 3000 gals of water in tanks to store heat. The downfall of the system was relays that switched between thermocouplers mounted in the tanks, I could never keep that relay working for more than a few months, just no current to keep the contacts clean. I eventually did a little re-plumbing to make the 2 tanks look like one big tank and eliminated the relay. Never had any problems after that. So yes, contacts do not like low currents, connectors are a lot better at low current signals, just don't do a lot of connecting and disconnecting.


----------



## RT_Coker

Thanks for the responses! Because this is only a test-product, long-term-connector-problems are concerns that are a ways done the road form where I am now.
I have one set of boards left. I plan on trying to put the two boards together with an 8-pin-connector that I can pin-mate with the end of the motor-driver-board. This will give me something like a DCC-decoder-board that I can test on my breadboard first.
Bob


----------



## RT_Coker

This is the first plug-in version of the BlueTrain3 locomotive-controller. It has been successfully tested on the breadboard. (I made one wiring mistake by connecting the rear-light to the wrong digital-output. But I will not be using a rear-light on the test-locomotive.) The large red-connector is just temporary until some smaller connectors arrive.
I also switched from a 9V battery to two 7.4V lipo-batteries. This changed the motor dive voltage form ~9V to ~15V, and revealed a problem with the BlueTrain firmware code. So after the firmware is fixed the next big step is to re-wire the test-locomotive with the appropriate connectors.
Bob


----------



## RT_Coker

Here is a document on the OS-DBTC hardware. It most likely has more than anybody wants to known on the subject. But at least it is “published” so that maybe the hobby can avoid having to work around a patent that should not have been approved.

I have order the parts to eventually build 4 more of these OS-DBTC “boards” for my use.
Bob


----------



## RT_Coker

Pictured are 4 “production” OS-DBTC “boards” that are basically like 4-function HO-DCC-decoder-boards only without a direct DCC-power-connection. One 2-pin-connector is for tachometer-input and mark-input, and the other 2-pin-connector is for F2 and F3 function-outputs. All 4 “boards” work as tested on the breadboard “loco” despite being assembled by my shaky hands and not-so-good eye sight. 

Next up will be an android app that will let me wirelessly control the “boards” Bluetooth settings. It takes a long time for one person to create all the different hardware/firmware/software items and then get them working together. 

This will be followed by rewiring the lipo-battery-power FTA for a “production” OS-DBTC “board”.
Bob


----------



## gunrunnerjohn

Lookin' good Bob. You're right, you're taking on a fairly large scope project doing all the pieces.


----------



## wvgca

it's good to see it all coming together


----------



## RT_Coker

A picture of the BlueRail/Bachmann HO-FTA board. Had an opportunity to buy a new one for $46-shipped to check out. The App installation had a resolvable glitch and that probably explains the low price. 
Not an expert, but the low speed didn’t seem very smooth to me and had the sound of an audible motor-drive frequency.
Bob


----------



## RT_Coker

The un-updated Loco-firmware 3.21 apparently has a ~400 Hz motor drive that is fixed in the updated Loco-firmware 3.45. The problem is getting the Loco-firmware updated.

Getting a “Connection failed” error after a brief “firmware downloaded and ready” message when trying to load new Loco-firmware version 3.45 over 3.21. Loco is a new Bachmann FTA and everything else appears to be working. Error occurs in both the latest downloads of the Bachmann and BlueRail Train Apps on two different Android devices. The internet connect is good. The apps downloaded and the updated Loco-firmware downloaded according to the app message “firmware downloaded and ready”.

It appears that a “Secure Over-the-Air Bootloader” (Bluetooth name RigDFU) is being used. Reference: https://www.rigado.com/deviceops-platform/. The process appears to require a connection to an internet site that does the actual Loco-firmware update as opposed to having the app do the Loco-firmware update directly. This site connection appears to be what is causing the “Connection failed” error.

Not much help from the B’man forum so far, and apparently no “service” option on the BlueRail Trains site. Looks like I will have to wait, until I can see my grandkid and can use his iThing.
Bob


----------



## RT_Coker

I browed an ios device, downloaded the BlueRail ios app, and successfully updated the loco-firmware to 3.45. The loco ran fine with the ios device. The loco is now much smoother and quieter at slow speed. 
Now the problem is that the loco will not run with either android Bachmann or BlueRail app. 
Bob


----------



## RT_Coker

The android apps on both my android devices would run the loco with loco-firmware 3.21. But my apps on my android (4.4.4) phone would not work with loco-firmware 3.45. But, finally some good news, the BlueRail app on my android (5.1.1) tablet works with loco-firmware 3.45. So I finally have a working android/3.45 setup, and can “play”.
Bob


----------



## RT_Coker

This uncompleted open-source Direct-Bluetooth-Train-Control project is ended! It is beyond my diminished abilities to complete. 

I will be selling my remaining train things on eBay.

So long and thanks for the help and support.
Bob


----------

