Brushless Axle Hung Motor System

[IanT]

No, I've not come across them Tim - but will look them up.

I'm still waiting for the sample ESC to show up but decided it made sense to pre-order a few bits in preparation. I didn't really like the idea of soldering wires on (and off) the SMD Micro's pins - so I've invested in a "firmware flashing socket tool" - in simple terms a removable clip that fits over the Atmega and lets you get at the required pins. These seem to be a Hobby King exclusive, so I had to use them. The price showed up in sterling but I was really paying in dollars at the going rate it seems.

Anyway, I also ordered some 4mm gold connectors for the motor leads (makes the motor/ESC plug & play) and a "USBasp" (USB Atmel Serial Programmer??) which is required to actually re-flash the chip if I need to do so. The connectors/USBasp were shipped very promptly from a UK Warehouse by 1st Class mail. The socket tool is still on its way from Hong Kong.





Been busy this weekend but I did a bit more research into ESC firmware. A picture is emerging of a rapidly changing state of the art in terms of drone ESC firmware. Originally, the software was just proprietary but then SimonK emerged, together with BLHeli and there is now a third option KISS. From what I can understand, SimonK has not been further developed recently, whereas BLHeli and KISS have. SimonK uses a PWM protocol but BLHeli and KISS also offer "1-Shot" protocols and most recently "D-Shot". As the names suggest, these provide single instructions to the ESC (but are still analogue), whilst D-Shot is now a fully digital system. The development is being fuelled by the need to speed up motor responsiveness and by newer/faster flight controllers. So I feel that drone 'tech' is probably moving away from our needs. It's also becoming apparent that there is no standard ESC design - the SimonK firmware has many configuration choices by model. This may be a real problem when trying to 'mod' a cheap (e.g. no-brand) Chinese ESC clone...and most especially when trying to help others do the same...

So it may be that Option 1 is do'able but hard to replicate reliably. There are ways around this problem but they fall into Options 2 & 3, only time will tell. But one step at a time for now.

Regards,

IanT

[Doddy]

Ya'll might want to have a look at the Deadrail Society as well. These guys have working solutions for G scale locomotives AND a DCC output for driving DCC Decoders with Sound cards.







AristoCraft have re-released their hand held controller and receiver (albeit under a new trading name)

So three potential avenues for solutions. In the meantime BlueRail has this to say on their future . . .

Hello from BlueRail,
"It has been 2 years since Bachmann released its EZ App trains, and 18 months since the Blue-Horse plugin board released, so it is kind of our birthday. It is great to know thousands of people are enjoying direct bluetooth train control. We are down to our last 75 blue-horse boards in stock.
BlueRail has been collaborating on development of a next generation product. Because this is a collaboration, we are not permitted to reveal details until a product announcement is made. But I can say it is the best train control technology I can imagine, the prototype works great, and I think it's going to make a lot of people happy. The control app will remain compatible with the current BlueRail boards, so no concerns for obsolescence.
Your feedback and support has been invaluable in getting it right. Feedback we've received include desire for a small form factor, onboard high-end sound, support for various amperages, DCC compatibility, and continued DeadRail support. All of these have been taken into account. Thank you very much for your help in guiding the development process of direct train control."
Dave Rees
BlueRail Trains

- Doddy

[IanT]

Hallo Tim & Doddy,

I wasn't aware of Monocacy but I know I've looked at the Deadrail site before (perhaps you've mentioned it previously Doddy?). So I've now looked at both and whilst Monocracy seems to be a proprietary Blue Tooth system. Deadrail is more of a 'movement', in the sense that they are promoting a move away from 2-rail - towards other forms of control - but mostly (as far as I can tell) still using proprietary RC/BT/IR systems.

So very briefly in response, my current 'meanderings' are directed at (what I think of as) the 'traction' level - and particularly with respect to driving low-cost BLDC motors. I didn't find anything (on either site) that referred to anything other than Brushed DC. In some ways, many of us could sign up to the Deadrail community today - because we already use R/C to control our engines (our track already being "dead") - the only difference being the scale of engines involved.

Monocracy is a commercial Blue Tooth system and may well be of interest to some G3 modellers. However, I'm more interested in using (and maybe helping to develop) 'open' systems. Slightly off topic for BLMU's - but last week a MERG member demo'd a simple CBus system, built with MERG kits and a RPi. He had JMRI on his Android phone and was able to switch two pairs of servos from his phone (they were configured as crossings). So there is already an 'open' solution for layout control that is very affordable and can be configured in many ways.

In terms of engine control, I have an inexpensive (£3.60) 32 bit micro system, that uses an IR diode and which can detect commands from a Sony TV controller. So simple and cheap per engine - and I have complete control of the programme source. I haven't looked into them yet but there are also inexpensive (£2-£3) Wi-Fi and BT modules available can could be used to replace the IR sensitive diodes currently being used. An HC-12 wireless module currently costs less than £3, operates at 433Mhz and has a range of about 1Km! It can talk to up to 128 devices (e.g. engines) and two of them just look like a bit of wire to a Micro's serial port - so simple (or not so simple) commands can be used to control your engines...

In case anyone is thinking "Well that is far beyond me" - this micro runs a high level language and is programmed via it's serial port. So any software developed can be downloaded using a text file and a USB connection. In other words, it's not hard to do once the bits are 'assembled' (e.g. wired together) - which shouldn't be any more complicated than most existing R/C system - and much more versatile. This could be the G3 version of a drones flight controller - and it should of course be configurable to manage the engine type being controlled - be it powered by BLDC, Brushed DC or Steam...

OK, that's for the future - back to the current knitting and BLDC ESC drivers ....   :-(

Regards,

IanT

[Doddy]

Hello Ian,

I would not describe Deadrail as a movement, unless you count the support and direction of Bachmann for doing so. The product uses a DCC interface allowing users to choose their own DCC decoder supplier (with or without sound enabled). Since many DCC controllers have high power outputs, then small to medium G3 locomotives could easily be powered. And driving multiple DCC controllers could easily power larger locomotives.

But then we move into the area of ESC's and the escalating costs of providing an ESC per motor, and a multi channel ESC controller. Since most software is for the Drone market then your proposal of a multi channel ESC controller kicks in.

Assuming that the drone motored locomotive has to have fine control at low rpm speeds, this does adda compromise in that at lower motor rpm, the control is synthesised anyway as the feedback from the motor to control synchronisation is reduced and would require FET's to tell the controller how the motor is operating.

If you can get that lot working I'll gladly tip my hat to you.

Best regards

Doddy

[IanT]

Well just sticking with the thought that small BLDC motors might be very useful, then yes, each one needs a low cost ESC to drive it.

The problem then becomes that drones use high speed (sensor-less) BLDC motors that generally use zero-crossing detection to work out the rotor position. I think you are alluding to the fact that this (Z/C) doesn't work too well at low speeds because the BEMF is much lower. However, there may be other options available - such as adding sensors, 'estimated' timing or look-up (sine-wave) tables.

But first I need to look at the bog-standard stuff and see if it can be used...

In terms of the next level up - sending control signals to the ESCs - I'm much less worried about that - it already exists in various forms (and could be implemented with Brushed DC already if required)

Regards,

IanT

And you are correct - I have no idea if an affordable low-speed BLDC ESC is possible.   :-)

[IanT]

Well my ESC arrived this afternoon - and all I really know about it is that (in theory) it can cope with 30A (max) and has been flashed with SimonK firmware.





So, the next step is to try and find out a bit more about it - and anyone who is interested in the detail of this (Tim?) should probably start here: https://github.com/sim-/tgy/wiki/Identifying-ESC-pin-configuration

So, I cut off the heat-shrink and this is what I found;





The MCU is unmarked (?!) apart from the corner 'dot' (which allows pin identification) but I think it's safe to assume it's an Atmega chip. The small chip in the top right is a 5v regulator (for the MCU I assume) and the circuitry to the left are the discrete FET drivers. Underneath there are the FETs and two 78M05's (for the BEC I think). Unfortunately, the aluminium heat sink is attached with some white adhesive (silicon?) that is holding on a lot harder than some of the videos I've watched suggested it would. I don't want to apply too much force at this time, so I haven't been able to see what type the FETS are. I need to know this, so it's a real problem that the heat-sink not coming away easily...!!

But I think the larger problem this is highlighting - is that there are no hardware standards in this area - simply because everyone does their own thing to some extent. This is going to make coming up with an easily 'reproducible' solution (at least using these cheaper ESC components) very hard I feel.

Having explored the subject of 'drone' ESC's a bit further, it now seems that as demand for decreased 'latency' (how fast the ESC can respond) has increased even the (hitherto 'open') BLHeli has now gone 'closed' with it's latest D-shot version (BLHeli 32). The ESC has to be registered with them to be able to use their programming suite. KISS (the other 'fast' firmware) is already proprietary. Drones  need fast response because the PIDs (basically what balances the motors on a muli-rotor drone) are getting faster and more intellgent. This just confirms my feeling that drone tech is moving away (in the wrong direction!) from what I need longer term to use BLDC motors in my engine(s).

Anyway - I'll see what further I can learn from/about this particular ESC (and clearly I've lots to learn still generally). I'll update you on any progress (or lack of it) I make.

Regards,

Ian

[IanT]

Well still no sign of the 'socket' cable that's coming from HK - but I have been looking at the SimonK source code to see what I can make of it.

I think a good analogy might be that whilst you don't need to be able to write a good book to read one - you do need to be fully literate to do so quickly. The source seems well commented, so there is no need to work at Atmega 'instruction' level at the moment but it's still much more complicated than a simple 'linear' listing, with much use of assembler macros and many constants interweaved. So I think it's decipherable but will take some effort to do so.

One point noted of interest (to me at least) is that the original code that SK is based on (written by Bernhard Konze) included an IC2 interface instead of the normal PWM one. This was a duplex connection and allowed the MCU to return current, temperature, voltage and RPM data to it's main controller. It also appears that at one time this was used by some ECU manufacturers (Afro & Blue) for 'reversible' ECUs - thus removing the problem of effectively halving the speed sensitivity when using PWM - something Tim has already referred to.

This all dates back to early flight R/C where all control was via servos (planes either being gliders or IC engined). I'm sure some here will know that the 'servo' control consists essentially of a variable length pulse (1ms - 2ms) that occurs every 20ms. So (in theory) full 'off' is a 1ms pulse and this increases to 2ms for full 'on' - with mid-speed being at 1.5ms. I say 'in theory' because in practice, the pulse width varies slightly between devices and this is why a servo (or ESC) has to be calibrated against the TX/RX.

So if we introduce reversing into the ESC, the 1.5ms pulse width becomes not 'half-speed' but the 'off' position and the 1ms becomes full reverse and 2ms full ahead (or vice versa dependent upon the firmware setting). This is why a normal ESC will lose 'sensitivity' when controlling a reversible motor.

However, using an IC2 interface removed this problem, as it simply tells the MCU to reverse the rotor sequencing and the speed sensitivity is simply a matter of what bit-level is used in the speed commands issued - being the same for both directions. Unfortunately, as far as I can tell, neither Blue or Afro currently offer IC2 ESCs - they are all PWM ones. So I guess the idea never caught on in the boat world (probably the IC2 RXs required were proprietary and therefore expensive). Some hardy adventurers have hacked PWM ESC boards and used IC2 but this seems to involve cutting tracks and moving pin connections - something that just adds to the complexity of the overall work required. As already mentioned, the modern trend seems to be towards fully 'Digital' but I think they are going to be closed (e.g. proprietary) systems.

Whilst I'm awaiting the HK cable, I still need to build some other bits and bobs, maybe a PWM pulse generator (an Arduino based one should be easy) and power 'limiter' (a 12v car bulb in the cable) to help prevent anything going 'bang' if I get the ESC set-up wrong! I do know now that it's an all 'N-FET' design - and indeed I have found that the round pads (that can be seen in the photo) are the so-called 'programming' pads - usually found on the PCB edge in older designs. These give access to the MOSI/MISO (etc) pins required for re-flashing the chip but hopefully my socket cable will be here soon.





Once I've got a basic test rig set-up and running - we'll have a look at what's going on around the Atmega and see what we can figure out...but don't hold your breath!   :-)

Regards,

IanT

[IanT]

Still no sign of the cable and I haven't found that 12v car lamp yet either ( I have some spares from the old car somewhere). So I'll have to pop into Halfords I guess and part with some more pennies.

I've been looking at the SimonK source again, not a task for the faint of heart (such as myself) as it runs to 82 pages of print. In the end, it occurred to me to copy the text into Word (leaving everything in the original file intact) and then I could mess around with it however I wished. So I've been able to highlight all the commentary (in yellow), key macros (in green) and bits I probably don't care about (in red). There's a lot in there but it's possible to find the more important bits and hopefully help me to try and understand what can be done within the available code options. I'm not going to try to modify any code at this point (although the specific assembler SK used is still available FOC).

There is a German utility (KKMulticopter) that let's you change most settings it seems and that will be my first port of call to start getting a reversible motor (and gentler start if possible). I have to get the test rig set-up first - although I've also been looking at a simple way to drive the ESC this evening. I was thinking of using an Arduino Uno to generate the servo pulses required. But then it occurred to me that my Micromite + would be easier to set up and so it's proved.

Micromites are programmed in MM Basic but before anyone starts asking "Basic? Going back to the Stone Age?" - No, MMB is a very useable tool and very easy to set up for this kind of job.

Most 'embedded' environments require an edit/download/test/edit/re-download/test again type of regime - which is not ideal when de-bugging things. With MMB I can talk directly to the Micro from the keyboard and test code interactively. It's also very simple to drive things in the real world. To set up a pulse to a Servo (or ESC) I just need one line of code - e.g. "Servo 1, 1.5" - that's it. That will generate a 1.5ms pulse every 20ms! The small programme I've written just watches the keyboard, boundary checks it (is it between 1ms and 2ms?) then updates a variable called 'Speed!' and adjusts the Servo pulse (e.g. Servo 1, Speed! ).

I won't bang on too much more about this - but I'm currently running MMB on range of platforms including 28 pin DIP PIC32 (32 bit) Micros (which cost £3.60 each), some faster/bigger PIC32's, My Win10 laptop and a RPi 3. To give you some idea of what is possible these days, even the 28 pin PIC32 chip has more memory, a lot more I/O and runs about an order of magnitude faster than most 70/80's style 8-bit home computers used to -the 28pin MM is capable of 30,000 lines of Basic a second - and you can do an awful lot of things in that time

And with progress on the main project still probably being best described as 'slow' - I was pleased that I had actually got something working tonight - small steps...  :-)
   
Regards,

IanT       

[John Candy]

but before anyone starts asking "Basic? Going back to the Stone Age?"

Gosh.... you are making me feel "Neolithic"!
I am afraid I have not kept up with recent computing developments like Arduino and Raspberry Pi, so most of what you are writing is going "over my head"..... but I do remember having great fun writing  programs in BASIC to run on the first generation CP/M micro computers in the City office during the 1970s/80s!

Regards,
John.

[IanT]

I built a Z80 system in 1979 John and it had an 8K Basic in ROM. The operating system was C/PM and although not very 'User Friendly' a few simple commands were all you really needed to know. Even Z80 assembler was fairly straightforward once you had the instruction set handy. In other words I could get my head around things generally.

These days, systems (even on a single chip) are much more complicated, the tools involved are often very powerful (but also complex) and pretty hard to understand easily. Despite it's many detractors, I use Windows 10 day to day for most of my work (email, internet, CAD etc) because it is easy to do so. However, don't ever try getting 'under the hood' - that's far from friendly - and it's extremely hard to "talk" to the real world from a PC too.

Modern Micros are very much more complex than the old 8-bit ones. The PIC32 has a very simple (MIPS) instruction set - but there are hundreds of control registers and thousands of option 'bits' that all need to be set-up correctly. This is all handled by the manufacturers 'tools' (compilers) provided you tell them what type you are using (they are all different internally - even for the same chip 'family'). With the old Z80 the only real choice was the chips speed, pretty much all else being common. So again, a lot more power but a lot more underlying complexity too.

Frankly, I don't have the time to get into much of this technology but there are things I'd like it to do for me. So I've had a good look around at what's available and decided that MMB can do most of what I need (across the platforms I use). I have another tool/chip set I'm learning where absolute speed is essential but MMB will cover most of the things I need I think.

Looking forward, I've already mentioned that I intend to write an engine control/management system (not based on flight systems) and as MMB gives me easy access to I/O (digital, analogue, PWM, Servos) and Comms (Async Serial, I2C, SPI, RS232, IEEE485 and 1-wire) this is probably the route I will go. Another MMB option (Pi-cromite) is to run it on a RPi Zero W - which is extremely fast, quite small and has built in Wi-Fi.

However, a PIC32 Micromite can support up-to five Servo/PWM channels - so my 'Servo Pulser' could easily be adapted to manage a multi-motor setup - and because it can respond much faster than any "finger" could do - may be able help with making 'standard' ECSs & BLDC motors more amenable to our needs than they might otherwise be. We will see - I still need to explore what can be done with the existing tech first.

Regards,

IanT               

[John Candy]

I seem to remember (perhaps incorrectly) that the micro computers I sourced for the "office" back in those days were called "Ontel" (not Intel) with 64K and utilised "Winchester" disc drives with removable discs (the size of a dustbin lid but only held something like 10MB)!

Seems like a lifetime ago...oh, it is almost, doesn't time fly!

Regards,
John.

[IanT]

I'm afraid it does John!  :-)

In the early 70's I was on 7 x 24 hour callout for our largest customer in the West Midlands and their 18bit 'Mini' (PDP15) had two 32kb (yes - kilo byte!) fixed-head disks that were pretty reliable but took 8 hours to re-build if a head "crashed". That installation probably costs hundreds of thousands to install - and many thousands per year to maintain and it lived in a purpose built A/C room 40ft x 25ft.

My Micromite Plus lives on a board about 25mm x 75mm, has a 32bit CPU running at 120Mhz, with 512K flash, 128k ram, 45 I/O pins all "on-chip" together with on-board USB and a 32Gb SD card for data and programme files. It cost me less than £30 (pre-assembled) complete with the SD card.

So I do think it's very hard (not just to keep track of all the technology) but to also adjust our expectations of what we can now use this stuff for. I guess there are many folk who get used to a particular approach that works and that's "Good Enough". I think our current use of R/C kit falls into this area - and that's fine if that's all you need.

There are also a lot of experienced Hobbyists out there who, having learned the (then current) tech from about 10-15 years ago (typically smaller PIC chips running assembler) ask why throw a 32bit chip at a problem, when a smaller/cheaper chip will do it. Well, if I'm only going to need a handful of 'systems' for my 'custom' compute needs - then frankly I don't really care if the solution costs me 60p or £3.60 - I'm going to use the easiest/quickest one to learn and just throw compute power at my problem.

And I'm also pretty sure that within another 10-15 years, all this current 'tech' will also be looking pretty obsolete - but I may not care by then....

Regards,

IanT

PS It's always dangerous to start remembering back "then". There were also no Mobiles either - so once I had collected my 'jobs' for the day (and had left the office) - I was pretty much my own master. I suspect it wouldn't be nearly as much fun these days...   :-)

[Doddy]

8 Hours? WOW! The Ericsson Datasaab series 16 disk drives I looked after (CDC Pheonix, CDC Hawk and AMPEX 60mb) took two and half hours to rebuild. Thankfully I was not on a 24*7 call-out though.

I am taking a different approach with Aristo-Crafts old radio technology and an audio sampling card interfaced with a processor to control different acceleration and deceleration profiles with an appropriate sound bank.

I'm going for analogue control, but keeping my eye on developments with Brushless technology.

[IanT]

Ys, it was quite a job Doddy.

You had to completely remove and strip the unit (imagine a very large suitcase), change all the heads and the 'platter'. This was a chrome (?) plated disk about 30" across and 1/4" thick - and it had to be waxed to a very high shine with a special wax and lint free-cloths. Once re-assembled, the moment of truth arrived and you had to turn it back on. The trick was to gently rotate the spindle to and fro and give it a final flick as you threw the switch. The heads 'flew' (at a fraction of a hairs breadth) over the surface of the disk - and if any one of them touched down during start up - it was another 8 hours (plus waiting for the replacement parts to arrive). Could be a very long weekend.

I've built a simple test stand this evening - just a ply bracket to hold two motors (I've been wondering if it would help to physically connect them - but 30 degrees out of phase. One could be full on, as the other was transitioning - it might help smooth slow running I think. It may not be necessary (or even desirable) but just in case I want to try it out....

It's also occurred to me that not all the MM's (a 3.3v device) Servo/PWM pins are 5v 'tolerant' (three are - two are not) and I'm bound to do something daft to the 'in-tolerant' ones without thinking - so I've ordered a couple of 4 channel level converters (£1.60 each) and will always connect one between the MM and the ESC(s) just to be sure.

I know this all sounds pretty complicated but if (once) I can figure it out, then hopefully it will be much simpler to copy. These little BLDC motors really are a very neat physical solution to anyone needing small (powerful) 'traction' motors (e.g. most modern image) but they do need a lot more electronic trickery to drive them than a brushed solution.

"I am taking a different approach with Aristo-Crafts old radio technology and an audio sampling card interfaced with a processor to control different acceleration and deceleration profiles with an appropriate sound bank." - Is this the tech from the 'Deadrail' guys Doddy?

Regards,

IanT

[Doddy]

"I am taking a different approach with Aristo-Crafts old radio technology and an audio sampling card interfaced with a processor to control different acceleration and deceleration profiles with an appropriate sound bank." - Is this the tech from the 'Deadrail' guys?

No Ian. I am planning on using the 2.4Gig Revolution Transmitter and Receiver previously developed by Aristo-Craft and now marketed by http://www.revoelectronics.com/

The 16/24bit audio sampler card is available off the shelf for £35 and has 32Gb of memory and an ARM-7 processor. I am going to feed the output of the Revolutions Receiver into my own design of control card and then on to the various systems connected to it, such as the sound cards, motors, smoke system etc.

Like all things in life, my project has been stalled for some time due to unstable home circumstances. Hopefully 2018 will turn out better than 2017 and I can restart the project.

Doddy