The Forum for Gauge 3 Model Trains

Well this particular project is still in the very (very) early stages but I'll start here as the 'motors' arrived today.

I'll state straight away that others here have already trodden this particular path, including Gavin_G and Doddy. Tim has also published details of his very interesting brushless design in the Summer 2017 NL. However, Tim's design didn't really fulfil my current requirement and I am still looking for something that is essentially an 'Axle-Hung' design - because that what my prototype had. I will also state quite clearly here that I am not an electronics or mechatronics expert, so I'm afraid this will be very 'suck-it-and-see'.

As Tim states in his NL article, one way to measure (size?) brushless motors is by their Kv value, which in very simplistic terms gives their RPM/volt. As most of these motors are designed to be used in drones these days, they tend to have high Kv values but for our needs a lower Kv is preferable. My other criterion was cost, as if this doesn't work out, then I didn't really want to have spent too much money finding out I'm as dumb as I think!

So I looked around and most of the lower Kv motors tend to be quite large and also quite expensive. Tim's are 620Kv but many of the cheaper ones are 3500Kv units. Then I happened on a DIY 'Drone' site where the builder was using smaller BLM's that would fit my application size requirement well but were (only) 1000Kv. He recommended them and stated that purchased directly, they were very affordable and in reality exactly the same as branded products from the leading "manufacturers". I checked and was very surprised by what I found.

Suffice it to say that I've just purchased Qty x4 1000Kv motors with fittings (and propellers) for £11.79 - including delivery. They were ordered on the 4th January and arrived this morning. So for less than £12.00 I have my 'experimental' motors. Purchased locally (in UK) they seem to cost about 3-4 times that each. As there is no duty or VAT on items under £15.00 as far as I can tell - this seems to me to be a wonderful bargain. Only time will tell.


(http://thumb.ibb.co/md4596/IMG_4960.jpg) (http://ibb.co/md4596)


(http://thumb.ibb.co/hBa1hR/IMG_4961.jpg) (http://ibb.co/hBa1hR)

(http://thumb.ibb.co/dVzNp6/IMG_4962.jpg) (http://ibb.co/dVzNp6)


Regards,

IanT

Excellent Ian.  Please keep us posted.  These motors do look interesting as they seem more like the "normal" motors we use in that the outer casing is fixed and the inner rotor and shaft spin; unlike mine which is an "outrunner" design.  May we ask your intentions in terms of gearing?  Those shaft adaptors look useful too; could I just ask the shaft diameter please?  The drone market is so huge that developments there are going to be a rich source of low-cost opportunities for us. 
Keep up the good work (maybe an article for the new editor's consideration?  ;D).
Regards, Tim

I'm afraid not Tim - they are Outrunners - commonly referenced as A2212/13T and available from a number of different sources it seems, although one suspects they all originate from the same Chinese factory. The spindle diameter is 3.2mm - the motor diameter is 28mm and total overall (spindle) length is 40mm. There is plenty of room to fit within a G3 wheelset.

They have a max power rating of 150W, although hopefully I won't have to use anything like that. These motors are intended for use in a drone (and not a G3 loco) and we have very different requirements. Drones need high speed, high torque and lightness but have plenty of air-cooling available. They draw high currents for a relaively short period. We need fairly high torque but at much lower speeds and cooling may be a problem. Weight is normally not an issue for us and longer battery life is also desirable.

I've started on a first pass of the CAD and I'm using a single stage gear-set using M0.75 gears (60t x 15t) to give a 4:1 reduction, which I think will be sufficient provided the controller can help things out. In terms of the unit size, I needed a shorter frame to fit two units inside the chassis back-to-back but the wheels are a bit larger than most DMUs for instance. My initial design is 90mm from axle-centre to the back of the motor/gear frame but they could be made more compact depending on gearing and final frame design. The motor itself is very small for the potental power - I just need to feed it appropriately - but that's for another post...

Regards,

IanT   

Oops!  Quick correction - that should have been 45mm (not 90mm).  :-)

Regards,

IanT

Just to give people some idea - the Brushless AHMU could end up looking something like this.

It's just a first-pass draft and already a few improvements suggest themselves but it's still more compact than my previous AHMU efforts. Hopefully they will eventually be of use to other G3 folk too....  but that's enough for one evening I think.


(http://thumb.ibb.co/dHqOU6/GA_040118_M_75_Brushless_A2212_13t_Shilden.jpg) (http://ibb.co/dHqOU6)

multiple image hosting (http://imgbb.com/)


Regards,

IanT

Tuesday is always a busy day for us - and especially so this week as the monthly MERG meeting is tonight. We (well the others) have been building a small ATC demo system (in N gauge) to explore how the MERG kits work in this area. It's proving to be more complex than I thought it would be but seems to be getting there. The next project is a similar 'demo' layout but using CBus kits - which is the area I am mostly interested in. We are blessed with having some very clever people in our local MERG section who fortunately seem to know a great deal about electronics generally and MERG kits in particular. Just as well, as I certainly don't yet.

But, back to a BLDC Axle Hung Motor Unit - I'll just call it the BLMU (Brushless Motor Unit) I think, as the technology can also be applied to other forms of drive. However, my reference to 'system' was appropriate as it's already very apparent to me that the 'mechanical' aspects of this BLMU are relatively simple compared to the electronic/system requirements. We are all generally very familiar with "ESC"s but these have traditionally been for brushed motors. As far as I know, all of the commercial ESC's (for model railway use) are brushed ESCs (although someone may be able to correct me). So this is the next area to explore and there are a number of possible ESC approaches that I am currently aware of (although my knowledge in this area is still very limited). I'll try to headline the main ones but will only describe them very briefly for now.

1) Low cost 'drone' ESC's. A suitable one for the A2212 would be one of the inexpensive 30A ESCs (about £2-5 each). They are designed to be air-cooled but their biggest problem is that they ARE designed for Drones. As such their firmware has many features that are good for drones but not for traction engines, not the least being that they are not reversible. However, others have 'hacked' them and re-flashed their firmware to suit their needs. There are also relatively low-cost "Boat" ESCs - which are reversible and have a water-cooling facility. These can be obtained in the £7-10 range. All of these ESCs use a servo connection to receive commands.

2) Separate 'Driver' & 'Logic' solutions, whereby the amperage is delivered by a power board controlled by a separate processor (typically Arduino). This has some attractions but most of the examples I've looked at so far (and I've not been looking that long) are fairly simple and probably do not offer the facilities I'd really like to have (and be able to develop). On the plus side, I could use my preferred MCU and software to develop the firmware - which is really going to be the heart of any ESC solution.

3) And currently the most promising - it turns out that others have walked this path (for different reasons) before [hardly a surprise] and that a seemly very sophisticated ESC solution already exists in the form of public domain hardware and software. This solution has many of the features I know I'd like to have (plus many that I hadn't even thought of). On the downside, it is quite complex, costs are hard to estimate at this point and it involves a completely new 'tool-chain' (to me that is) as well as being hosted on Linux (again a foreign place for me).

So I think that's an overview of where I am with ESCs at the moment. Any model using brushless motors has got to have a suitable ESC/control system specifically designed for it to work well. If my 'travels' in the area are of interest to folk here, then I will provide more detail and provide links to various source information. If anyone here has useful hints/tips for me in return , then I'd be very interested in hearing them.

For those of you who are not interested in all the 'tech', then don't despair. I'd like to get to the point where anyone can download some firmware, flash their 'chip', connect their motors and have a usable BLMU (or maybe buy them from the G3 Shop?). I'm not sure if I'm the person who will deliver on this but if not me then I'm sure someone else will eventually - and I'll have had fun trying.

Anyway, time for dinner and then perhaps a rather rainy/windy drive to the meeting.

Regards,

IanT           

Ian,
This is all very interesting but I fear that you are presenting the study as unnecessarily complicated.  That is if all you want is variable speed and direction on demand, as we generally do with brushed motor drives.  There is a big 'however', however, and that is that you need some more features or outputs, hinted at but not so far divulged.  If one of these is a drive to a sound card, can't one just take an output from the receiver speed channel via a 'Y' cable to drive it?  What else do you need?

The simple and non-specialist way was as I described in the Newsletter last Summer, that can be assembled by an electro/mechanical numbskull like me. This is to use a cheap drone ESC (your No. 1) and fit a reversing relay to a second channel.  I know this isn't the only way, and I applaud your diversity of interest into MERGs, CBus, Arduino, etc, but it's not a field that I will dissect.

One tip, as you have probably already realised, each motor will need its own ESC.  This is because there is feedback from the motor to the ESC so that it knows when to send the next pulse, so several motors on one ESC is going to be a recipe for sound and light effects! You will need 'Y' cables to connect several ESC to one receiver output.

As for cooling the ESC, don't worry there won't be a problem.  Each motor and ESC is only going to pass around 1-2 amps max as you are using multiple motors for a train. Just leave a bit of fresh air around them.

One problem for me was finding a suitable drone ESC to give acceptable low speed performance, so I wish you well in this field.  As these ESCs are so cheap it's worth experimenting with several.

Keep up the good work.

Hi Tim,

I was thinking the same myself as I drove over to MERG.  :-)

I guess my reasoning is that I have a number of 'hobby' activities (Home Machinist, Railway Modeller, Computing etc) and that they already over-lap to a greater or lesser extent. When I built my first Z80 CP/M system (late '70s), it used to be called "Home Computing" but these days my interests are directed towards what is termed 'embedded' computing. So I already have some knowledge in this area (but by no means a great deal of expertise) and I already have various 'micro toys' that I play with. However, after a while you start looking for real world applications to try them on. So that's what is going on here to some extent but I do hope that others might find it interesting and (eventually) useful too.

It's getting a little late now but I will touch on a couple of your other points very quickly.

I do realise that a relay will do the trick but I could probably also have squeezed a smaller brushed motor and gearbox into the space - there are always many ways to do things. In the short term, using the cheapie ESC may well be the way to go but even if I do, I'm already pretty certain that my set-up won't have relays. I know that there are different ESC types out there but I also know that some (those with an Atmega-8 MPU) can be re-flashed with new firmware to enable reversing and change other key parameters. For many here, that might be all they want or ever need.

But you are also correct to surmise that one of my longer term objectives is to move away entirely from using 'Flight' R/C technology to control my engines (and their interaction with my layout). I'd prefer to use other technology, enabling for instance control via tablets, phones or other intelligent controllers (e.g. RPi) - and all sorts of other functionality too. Just a pipe-dream of course but that's fine, provided I enjoy the trip - then that's all that really matters.

BTW - I am very pleased to hear that heat should not be a problem. I was worried that these little beasties might warm up too much and melt down if I wasn't careful with them!

So, I'm still going to look at all the options. As I go, I'll try to explain what seems to be available 'out there' and which way (and why) I finally decide to do - and of course how I get on (or not!).

Returning to my New Year thought - I hope others will start to describe their G3 'adventures' here too...

Time for bed.

Regards,

IanT

Just a short post tonight (you will no doubt be relieved to hear....) - but a little bit more about 'programming' 30A drone ESCs.

As I understand things, most drone owners 'mod' their ESCs via either coding sequences (from their R/C transmitters) or via proprietary 'card' programmers. Whilst these methods could be used, I'm not convinced that this is the best way to tune them for our use. However, it does seem that Atmega based ESCs can be re-flashed using public domain firmware referred to as "SimonK" (after the Author - Simon Kirby).

This YouTube by Robert Cowan describes the process very well:   https://www.youtube.com/watch?v=MQQX7IIdAtI and also gives some very useful links (for anyone who wants to research further).

Robert also gives a long list of suitable ESCs - however it wasn't obvious that the cheap 'yellow' ESCs available here from chinese sources were included. However, I then found some 'red' ESCs which are described as having "SimonK" firmware pre-installed. Since SimonK seems to only flash onto Atmega chips - it would seem these should be suitable for hacking - I mean re-programming.     :D

Anyway - I've ordered a red one and once I've had a better look at it (by cutting off the shrink-wrap) - I'll let you know more. It may be a week or two before it arrives though.

Regards,

IanT

"I hope others will start to describe their G3 'adventures' here too..."  Me too Ian.

Must admit that I understand about every other word of your recent posts, but I may benefit indirectly from them one day so thanks for doing all that work.

Mike

Hi Mike,

Like all modern technology, what's hidden inside is often very complex but that complexity usually comes in layers and hopefully we won't have to dive in too deeply here. A few people out there probably understand ESC 'tech' very deeply (Simon Kirby being one of them I assume) but sometimes we only need to know just enough to get where we want to be - and hopefully (for me) that will be the case here.   :)

But - however complex something may be inside, as long as that complexity is well hidden away and people can actually use the (modified) device easily - then that's all that really matters.

And yes, I'd prefer not to be the only one 'adventuring' here.... 

Regards,

IanT 

I'm already interested Ian if you are going to try and tweak SimonK firmware ESCs, as 12A versions of these are what I have ended up using!  Currently the start up and slow running is 'reasonably' smooth, but if that's an area that can be tweaked for more progressive ramping-up then so much the better. 
If that could happen with a centre-off and reverse then that would be a bonus too, but I'm not holding my breath.  Reason? By dividing up the usable range of the controller into forward and reverse, the sensitivity to allow smooth starting in either direction may suffer.  I'll be very impressed if you manage it!
Regards, Tim

I don't really know what's possible yet Tim - I'm learning this stuff as I go along.

The video by Robert Cowan clearly shows how to set some of the top level parameters (such as 'reverse') within the assembler listing. These soft 'switches' should be fairly easy to experiment with but anything beyond that would require diving deeper into the main programme. This will require knowledge of the Atmel dev tools and Atmega assembler - and I've only used Microchip tools thus far (and on PIC chips). So whilst I know some of the theory - putting that into practice will be an altogether different problem.

I haven't looked at what is involved with using Atmel tools yet either, although they are now owned by Microchip. So some convergence may already be underway I assume - perhaps in terms of their IDEs (Integrated Development Environments). I was briefly using the MPLAB (Microchip) IDE a couple of years ago but have been playing with other (high level) languages on PIC and ARM most recently, so will have to re-boot my skills again I guess.

This was also one of the reasons I felt it was worth looking at other ESC solutions - because (in the longer term) it might make sense (at least for me) to be using my preferred tools and chips if I am going to develop a more integrated system. However, that is all in the pipe-dream stage at the moment - and I think we can get something much simpler, much sooner with a bit of effort.

With regards "sensitivity" this may be a function of several things - not only the ESC capability, but also the R/C being used to generate the servo pulses for it. My understanding is that R/C Tx/Rx's have to be set-up to match their ESCs - as they both have a 'range' which requires matching (or calibarion). This may be something that can be 'tweaked' at the ESC software switch level for our needs - but we will have to see. Longer term I want to go to straight digital logic and move away from traditional R/C tech completely - but one step at a time for now.

Regards,

IanT

Hi Tim,

Was thinking about your 'sensitivity' problem earlier (whilst repairing a leaky shower tray - not my favourite activity  :(  ). I was thinking that this might also be linked to the multi-motor issue too - although you've already mentioned using a 'yoke' to divide the PWM pulse to two motors. I am currently planning to fit a motor per axle (in my case 4 axles) although with the power available that may not be really essential.

"If that could happen with a centre-off and reverse then that would be a bonus too, but I'm not holding my breath.  Reason? By dividing up the usable range of the controller into forward and reverse, the sensitivity to allow smooth starting in either direction may suffer."

One idea has occurred to me that might help in this area and also possibly be a useful step towards my longer term goals. Assuming I can get a 'workable' ESC/Motor without needing to dive too deeply in - I will still have to drive multiple ESCs using PWM (although newer ESCs are starting to use different firmware & drive protocols it seems - perhaps for this reason).

However, it might be fairly simple to place a device between the ESCs and the Rx - it would look at the incoming signal (and in the main) just repeat it out to the ESCs. I think there are a number of benefits to this idea. The first is that it immediately enables other 'Rx' options to be explored over time (e.g. Wi-Fi & Bluetooth). The second is that with some simple feed-back directly from the motors to the device (hall-effect or opto) it could co-ordinate the axle speeds, for instance eliminating any wheel slip (OK - I know hardly a problem in G3 but maybe an issue with independently driven bogies/axles). It might provide an easier way to 'calibrate' the Tx/Rx to the ESCs too and perhaps other things - but that will do for now.

Probably sounds complicated & expensive - but I'm pretty sure a "blue pill" would handle this with ease - and the ones I purchased last year cost about £2.60 each. For that you get a small 70Mhz STM32103 ARM CPU board which can be taught to speak Arduino or Forth (Hallo Ralph!). Looking at the Rx pulses coming in and echoing them out should be a fairly easy starting point. It's a kind of half-way house between my options 1 & 2.

I have been researching ESC firmware btw - and the more I learn the more I'm thinking that it might make sense to 'black-box' it - in other words, get a workable ESC/Motor combination and then do everything else in the 'layers' above that...we'll see.

Anyway - just a thought for now but maybe a possible next step... assuming we can get past the basic ESC issues...

Regards,

IanT

Ian, I assume you know of the American "Monocacy" system using Bluetooth 4 to control HO scale Trains? Currently it seems to be limited to about 1 amp and not many volts, but maybe they are developing something heavier-duty.
Regards, Tim

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.


(http://thumb.ibb.co/kp0gsR/IMG_4963.jpg) (http://ibb.co/kp0gsR)


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

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.

(http://thumb.ibb.co/gq0J7R/SS1.jpg) (http://ibb.co/gq0J7R)

(http://thumb.ibb.co/cMu0Mm/SS3.jpg) (http://ibb.co/cMu0Mm)

(http://thumb.ibb.co/jZXWSR/SS2.jpg) (http://ibb.co/jZXWSR)

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

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

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

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

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.


(http://thumb.ibb.co/dYxP1m/IMG_4965.jpg) (http://ibb.co/dYxP1m)


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;


(http://thumb.ibb.co/fnDxMm/IMG_4966.jpg) (http://ibb.co/fnDxMm)


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

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.


(http://thumb.ibb.co/hVop9G/atmega8_pinout.png) (http://ibb.co/hVop9G)


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

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       

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

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               

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.

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

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.

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

Quote from: IanT on Jan 29 2018 23:37
"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

(http://thumb.ibb.co/mA5Pm6/BR45_Logic_Diagram.png) (http://ibb.co/mA5Pm6)

An interesting choice of prototype Doddy.

I see the TX/RX system is bi-directional but that you can also control six auxillary items directly too. What sort of technology are you thinking of using in your homebrew controller - and I assume that these are six 'brushed' motors too?

Regards,

IanT

I will be using the 6 outputs to control direction and lighting as well as activating non-automated sounds like air horns and whistles. The DC brushless motors will be powered by battery using a modified 4QD controller interfaced to the Revolutions Receiver. The 4QD controller can be cascaded for double (or triple) heading via a connecting control bus. It also alleviates control issues for HST, Blue Pullmans, ICE and Acela train formations.

A separate interface board will take a feed line from the Revolution Receiver and activate an appropriate sound bank from the sound card. Thus allowing gentle changes in engine tone or thrashing engines dependant upon the users throttle changes. Thus bypassing the acceleration and braking characteristics and the soundsets embedded in the Revolutions receiver. It will also be able to take a standard R/C PWM input as its source of control.

Given that when somebody is successful in developing a multi-channel Brushless Motor Control System for railways, then my I/O card will be able to integrate into that technology as well.

Very interesting Doddy.

I've just had a look at the 4QD site (and their current range of controllers) but they seem to be all for brushed motors at the moment. I did notice that their smallest controller (SST 30A) was "programmable" via it's Picaxe micro, currently just with open loop PWM but apparently with closed loop (e.g. sensored motors) coming soon.

Are your motors sensored?

The Picaxe is programmed in a form of Basic which could "easily" (always a relative term) be ported to the much more powerful Micromite if it was useful to do so (but obviously not for a 4QD device). Interestingly 4QD make their Picaxe programmes available for download (and modfication by their users) so I will have a look at what they have done just out of curiosity. Unfortunately there's nothing "brushless" there (at least for now).

Regards,

IanT

Very quick update on my progress - as the cable I ordered has just arrived. I've not received the level shifters yet but may be tempted to just rely on a 5v tolerant Servo pin..

The reason being that I've found this video which seems to answer many of my questions with regards to what kind of ESC the "Red SK" versions are. This guy seems to confirm that they are 'straight' .tgy types but with an older version of the SK firmware. He then flashes it to the latest (2015) version as a test - and this is the source version I've been looking at. Although he doesn't alter anything - it should then be very simple to set the 'reverse' option and at least get the ESC driving forward and backwards. I'm very pleased to have found this, as it removes a layer of uncertainty (in an area that already has more than enough mystery from my point of view.)

So if anyone is curious - this is the process I will be trying to emulate as soon as I've got everything set up (and of course I haven't had anything running in either direction yet!! - but more small steps... )

https://www.youtube.com/watch?v=5WQfVI8v7aw

Regards,

IanT

Hi Ian,


I am still working on it but 3d printing has taken over.  I have been meaning to comment on your posts on the forum but never got around to it.  I have progressed from the video but still not got a complete solution yet.


The plan was to use a nodemcu to replace the arduino uno you see in the video to get wifi control.  It turns out this is not that simple.  I use the arduino to generate a sine wave (well 3 waves) and then the triple half bridge to amplify this.  This works well until the wifi part of the arduino intrupts and pauses the sine wave generator for a fraction of a second, leading to stuttering of the motor.


I have got over this by using a master/slave arduino,   one to do the wifi and one to just control the motor.  This works well and is thinking about it a better solution as it will allow for more expansion allowing lights and sounds etc.


I have a working solution I just need to replace the UNO with something smaller to make it small enough to fit in a loco.  I tried a tiny85 but that was to hard, next step is 2 nodemcus which will be around the same size as the rivo board.


Am more than happy to share code and ideas.


Gavin

Thanks for responding to my PM Gavin.

I've been tied up with other work the past few evenings but just about have the test rig ready - unfortunately my oscilloscope has just died (it was very old) and I probably can't fix it.  I will try some test runs anyway - but I am expecting to see 'cogging' at very low speeds. I think I have to further explore my original 'Option 1' a bit more before moving onto 'Option 2' - which is very much where you already are it seems.

Having said that, I have purchased some cheap Hall effect latches and have been pondering how best to fit them - as I feel that 'Sensored' drivers might prove to be the way to go for really slow speeds. However, I've seen a Sine Wave generator used elsewhere for BLDC and it was on my list of things to look at - as well as a current limiting approach. If I can keep it simple (and cheap) then that would of course be preferable.

I've a Uno R3 sitting around idle but for this, I would probably go straight to a cheap Blue pill (STM32 ARM) - half the size of the Uno, much faster and cheap. It can be flashed to handle Arduino code of course, although mine are running Mecrisp.

Whether I end up using a commercial ESC or a custom MPU - my general idea is to have a single chip (MMB) 'central comms controller', watching the motors, various sensors and driver commands. I haven't really looked at this layer yet but do know that others are using ESP2866s under MMB (my preferred HLL) - although they are using CFunct Serial Libraries for speed. This doesn't sound too different to your approach - and Doddy seems to have a similar idea brewing but with a proprietary R/C controller...

And - yes please.  I would very much like to see the details of your current set-up (hardware & listing) - although perhaps we should spare others here the dreadful detail ...   :-)

Regards,

IanT

P.S. For those who are following this thread in more detail, Gavins' very interesting video can be found here:

https://www.youtube.com/watch?v=wXZXCIT3-Ok

I look at the words - individually I probably know what 98% of them mean, then you go and put them all together and that's it, you might as well be speaking Swahili or Serbo-Croatia - I know, it's a magic spell, you've been talking to J K Rowling....?

No, oh, OK, it's to do with motors and that magic electric liquid stuff - Keep going lads, but...... it'll never fly.

Pmsl
Barry

That's the problem Barry - in our case we don't want them to "fly" - very much the opposite in fact.    :-)

But just suppose we could give you a simple wiring diagram, a couple of eBay links (for parts) and then a nice fellow member was willing to wave a 'wand' over one of the bits for you - and then all you had to do was find somewhere to install everything in (or near) your 'bogie' - would that be less intimidating and more useful?

Regards,

IanT

And talking about "understanding only 98%" Barry - I had to Google 'PMSL'

Must be my age...   :-)

Regards,

IanT

Hi Ian,

With apologies to everyone else this may get technical!!

For the "loco" end I am using a nodemcu esp8266 (brilliant little chips) for the wifi control.  This will then use i2c communication to currently an arduino uno that does the motor control  this will be replaced with either a arduino nano or another nodemcu.  This then runs though a triple half bridge amplifier which is mounted on a L6234 Breakout Board.  The motors are 2208 gimbal motors that allow very slow speed control.  I have modified them to allow a 3mm carbon fibre shaft straight though the motor.  There are some motors that are hollow shaft that can connect onto a 6mm slaters axle. 

This allows forward and backwards speed control with a reasonable turn of speed and good slow speed power as per the video.  it also allows a brake affect as the L6234 board allows this.

For the hand end I am using any mobile phone that can run a web browser to connect to a home automation hub running on a Raspberry Pi3 running openhab2.   This then connects to to the nodemcu via MQTT.  It is complete overkill for 1 loco but when you add signalling in as well it becomes very powerful.  There is another video on my channel showing how powerful this can be using amazons alexa to allow voice control for a signal system.

I am working on using the signalling system on Warton Road which will simplify the wiring as only 12v is needed along the whole 100 foot layout.

I cannot attach .ino files will try PM

Oh I forgot,

I have used this system to drive 2 motors at the same time.  As they use the same sine wave generator they are always in sync, the 2208 motors fit within a 3 foot wheel so perfect for a bogie.

G

Quote from: LankyTank on Feb 04 2018 16:59
but...... it'll never fly.

Well if we get it wrong it will fly!!!   Some of the motors can spin upto 20,000 rpm.  Put that on an A4 and you could in theory get to over 200 MPH for a guage 3 loco!!

Quite a bit to think about (and investigate) Gavin - thank you.   :-)

Regards,

IanT

Quote from: Gavin_B on Feb 04 2018 18:39
Well if we get it wrong it will fly!!!   Some of the motors can spin up to 20,000 rpm.  Put that on an A4 and you could in theory get to over 200 MPH for a gauge 3 loco!!

So making a model of a slipping Western Class 52 diesel hydraulic would work well then?

A bit like this one?  ;)

https://www.youtube.com/watch?v=r7gjYXQQN_k  :o

In all seriousness, thanks to the detailed technical postings by yourself and IanT, I looked for and found a Chinese Brushless Controller with FET and PWM control inputs, along with reversible direction capability.

They are on their way and will be evaluated soonest.

Well that certainly does give a whole new meaning to "wheel slip" Doddy...

Be interested to hear how you get on.

Regards,

IanT

Well a quick progress report (although perhaps not too much of that at the moment)

I finally had my test rig all set up and ready to go - and had checked that the expected PWM signal was still appearing from the MMite. So double checked the wiring (just as well), set the speed to zero (1ms pulses) and then took a deep breath and connected the battery.


(http://thumb.ibb.co/c34uwH/IMG_4968.jpg) (http://ibb.co/c34uwH)


Nothing (but no smoke or bang either - lets breath out) - although I got some beeps from the ESC, which was a bit encouraging. Typed in '100' for full speed (2ms pulses) and up she fired, so reduced to '50' (1.5ms) and the speed dropped, down to '30' and the motor stopped spinning.


(http://thumb.ibb.co/mrd4wH/IMG_4971.jpg) (http://ibb.co/mrd4wH)



It seems that I have some control from '31' up - but nothing from '30' down. I had to stop at that point but hopefully will get some more time in this evening. Thinking about it, 'calibration' is usually done by setting the Tx first 'full on' (high), followed by 'full-off' (low) - so that's the next thing to try and see whether that helps even out the control range.

So a small step forward. The good news, there was no "magic smoke" and my Micro can generate PWM signals that the ESC recognises. Beyond that, clearly I've nothing anywhere usable at the moment, so it's very early days and whether I can get these inexpensive BLDC to work still remains to be seen.

My next step is to see if I can 'calibrate' the ESC (or modify my PWM programme) and see what that brings - and then start looking in more detail at the SimonK firmware and its setup options. Clearly, Gavin has had much better results with 'Gimbal' motors (80t vs 13t) and his L6234 driver. I've already been looking forward at Option '2' - and some of the latest BLDC intelligent 'chippery' but I think it's worthwhile sticking with this approach for a little while yet before jumping off into another one. Then I can give a better idea about whether Option 1 is viable (or not) and maybe what could be further explored to make it so.

Regards,

IanT

OK - after 'calibration' the motor now starts at '8' - with no motion between '1' & '7'. Much better but it still spins fairly quickly on starting - too fast I think for our use.

So I tried to fool the ESC by switching between '1' and '8' quickly (trying a few pause combinations). Too short pauses between switching and nothing happens, too long pauses and it just starts and stops in bursts - starting quickly and then stopping just as abruptly. So I suspect SimonK is introducing a short delay before recognising a signal, as well as probably having a 'minimum' level before it fires up the motor too.

So the next step is to get the USBasp & Atmel 'probe' out and start looking at the SK version number and settings using the various drone ESC utilities. It's certainly not going to be as simple as just making the ESC 'Reversible' I'm afraid.

Regards,

IanT

Thanks Ian,

I recently found an article by Will Sweatman with links to articles and PCB designs for a L6234 based three phase motor driver. Everything worked well at high speeds but for slower speeds the motor was choppy.

The problem was solved by changing over to a sine wave to drive the motor, but instead of the Arduino calculating the wave he moved away from using 36 steps in the software and used a lookup table of 128 steps for generating a sine wave modulated PWM signal.

This video shows just how slow the brushless Gimbal motor can move.

https://www.youtube.com/watch?time_continue=2&v=667XSSxieXM

Somebody posted on Will's blog that as BDLC motors are structurally similar to stepper motors, just with less steps, it occurred to me that stepper motor technology might be worth investigating for G3 applications.

This is a completely new area to me, but I think I am beginning to catch up with some of your terminology and the processes that you are applying to your respective designs.

Thanks to you and Gavin posting on your work, this opens up a whole new area of the hobby that would have otherwise remained in the dark.  8)

Good morning Doddy,

Yes, I'm aware of the BerryJam site and he's got some very useful thoughts on it. He does seem to be using a 'Gimbal' motor though and these are a little different from "power" motors, in that they have more 'teeth' (Gavins' motor is an 80t - mine are 13t) and apparently use a finer/thinner wire on the rotors.

Without going all technical (because I frankly don't know enough to do so) my limited understanding is that a 'Gimbal' motor is somewhere mid-way between a 'Power' BLDC and a 'Stepper' motor. All work on the same general principles but the 'power' one is designed for continuous rotation, the 'stepper' is designed to - well - "Step" (defined amounts). A Gimbal is somewhere in-between the other two, designed to react quickly to feedback 'loops' but not defined steps per se. It generally drives light loads over short distances - keeping a camera level for instance.

So we have these different design characteristics, plus size, weight and cost to consider. We are not too concerned with weight - although generally with extra weight comes increased size and that may be an issue for us. Cost is important, because we also need to add on the extra potential cost of the electronics involved in BLDC - so the real cost of a BLDC 'solution' is the motor + its electronics.

I don't know where we will end up with this but I think the context is that we don't really need 'ultra' slow speeds, just "slow enough" (with sufficient torque) to enable an engine to move off with a good load. We will have multiple motors at our disposal and (at least in my case) they will be lightly geared (4:1). I've already run some speed estimates in fact.

With a 4ft diameter wheel, an engine (at a scale speed of 1 mph) would require a wheel rotation of 420rpm, which (at 4:1) gives a motor rotation of 1,680rpm. That's 28rps (seconds) which on a 6 rotor-pair BLDC engine (e.g. mine) needs commutation at 168rps. I've a table of higher scale speeds but you can easily work them out and you will find we are moving up into quite usable motor speeds at a scale walking speed.

So I think the issue is that initial 'shove' and low end torque required - till we get moving.

There are some other very interesting videos out there covering some aspects of this problem but perhaps it's best if I point to them as we reach that area and explore them in more detail. Other duties (and my Manager) now call I'm afraid...

Regards,

IanT

   

Well, it's been a week since I last posted - so maybe I should update this thread.

I've had a few other things needing my spare time recently, so efforts in this area have been both limited and somewhat frustrating. From the videos, it looked easy to examine and configure the ESCs firmware. However, it has proven to be not quite so simple. My first attempts to use BLHeli just didn't work. So I decided to take things 'step-by-step' and recheck everything methodically.

My first thought was that the new 'socket' cable might be wired incorrectly for my USBasp version, as I wasn't using the (arduino) cable provided with the USBasp and as it didn't come from Hobbyking (like the 'socket' cable) they were from different sources - and neither had any documentation that I could find (the downside of using low-cost parts). The USBasp didn't have any signal markings on its 10pin O/P at all and terminated (at the end of its cable) in a 6pin connector board (which was marked). So I had to trace the pins 'backwards' to identify the right pins on the USBasp and then back again out into the new 'socket' cable. As it happened (after admittedly getting myself somewhat confused) I decided that everything was actually OK.

So I looked again and then realised (Dummy!) that there was no USBasp 'driver' loaded. The new driver was easy to find and download but my laptop couldn't see or use the driver, because it was "unsigned" - and Win10 steadfastly refused to use it. It turned out that there are several solutions to using "unsigned" drivers but in this case the best one was to use another (free) utility called "Zadig". Once this was downloaded, I was able to "sign" the driver and the USBasp now appeared (in my device list) when plugged in. Great (I thought) that should finally sort it!. But still no joy with BLHeli and its 'verify' routines.

OK I thought, I'll try KKMulticopter instead. This was downloaded (and unzipped ) but it wanted the Java Runtime Environment (JRE) loaded to run. So I downloaded the latest Java version and installed it. KKm couldn't see it. More headscratching/googleing ensued and eventually I was pointed at the Win10 Environment Variables, which can be reached via the Control Panel. This is where I had to leave off but I think I'm in the right area and a little more effort may well get me there. It's the usual thing, it's always hard the first time around, until you know what to do & where to go and then (with hindsight) everything becomes much easier. Unfortunately, you still have to plod through learning everything (and going down dead-ends) that first time around...

Whether or not, this is a good use of my time, I'm not really sure but I will stick with it for a while longer. I have been looking at other BLDC 'driver' options (and have found some interesting devices to research) but that's probably enough news for tonight.

Regards,

IanT

In the absence of Chinese brushless motor and controller deliveries, I had a look at an alternative mode of power.

https://www.youtube.com/watch?v=fDq82yJGW3U

That brought a smile to my face!

It's a wonder some "do-gooder" hasn't reported them to the RSPCA!!!

Regards,
John.

P.S. Anyone tried linear induction? At school, in the mid-60's, we set up a short track in the science lab!

Quote from: John Candy on Feb 15 2018 18:37Anyone tried linear induction? At school, in the mid-60's, we set up a short track in the science lab!

Not myself John, but the Tomy Toy Company of Japan has released its magnetically operated Maglev Train.  ;D

(http://thumb.ibb.co/hnzhfn/takara_tommy_linear_liner_4.jpg) (http://ibb.co/hnzhfn)

(http://thumb.ibb.co/kcoVY7/IMGP5666.jpg) (http://ibb.co/kcoVY7)

(http://thumb.ibb.co/j56jt7/IMGP5667.jpg) (http://ibb.co/j56jt7)

(http://thumb.ibb.co/crXqY7/IMGP5683.jpg) (http://ibb.co/crXqY7)

(http://thumb.ibb.co/mQvcD7/IMGP5673.jpg) (http://ibb.co/mQvcD7)

(http://thumb.ibb.co/dphPt7/IMGP5681.jpg) (http://ibb.co/dphPt7)


https://www.youtube.com/watch?v=xirz7Zm8t6w

https://www.amazon.co.uk/Linear-superconducting-linear-system-Special/dp/B00Y1UOL7I

We built a gauss gun in the 6form. It could embedd aluminium pencil sharpener in the plasterboard walls. The impulse capacitor was made from cooking foil and waxed bread paper. I did get to see the flying tea tray at BREL Derby.

Regards

Ralph

I can't remember a lot about the linear induction train we built....it was more than 50 years ago.....but we used brass curtain rail and "runners" for reasons of economy!

John.

I suppose we could always try breeding smaller Hamsters?  (it might be quicker!)

:D

IanT

Before I did anything else tonight, I set-up my test rig and checked the ESC was still working. I was concerned that I might have fried the Atmel along the way. Fortunately, everything still seemed OK.

So I went back to BLHeli and finally decided that my laptop still wasn't really seeing the USBasp device - although it was there according to Win10. After an evening of messing around trying different driver versions/sources - I finally found (and re-installed) one that has allowed me to 'Verify' the firmware as SimonK version "tgy.2012_09_30" - comparing it with the tgy.hex file on my laptop. BLHeli confirmed that the ESCs firmware was identical. Progress!

So in simple terms I now know that the USBasp driver and socket cable can 'read' the Simonk firmware on the ESCs Atmel chip. I also know that the SK firmware is not the latest (2015) version - so the next step will be to try and update (re-write) it - and then modify it.

But not tonight, that's enough for one evening I think.

Regards,

IanT

I was a bit tired last night, so (before I forget the details) and just in case I (or anyone else) wants to replicate this process...

The driver issue was solved when I found an Australian supplier (Protostack) that has a USBasp device that looks remarkably similar to my eBay 'LC Technology V2.0' one. Their website lists their own (AU$18) device but also has a 'Manual' for their version (complete with circuit diagram/cable pin-out) and also "signed" drivers. These drivers (in my case x64-v3.0.7) are 'embedded' into a .exe file that loads the selected driver (either 32 or 64bit version) onto your Win10 device. So I couldn't use Zadig - but this process did apparently overwrite the other driver I'd used with the new one.

https://protostack.com.au/shop/accessories/usbasp-avr-programmer/

I did have to run it twice to get it to work though, not sure why - maybe finger trouble on my part.

Regards,

IanT

Well, I got tied of thinking rather than doing, and I decided that if I don't start doing, then nothing will get done. And after the recent arrival of my LGB Ballenburg Steam loco, and in the absence of my own G3 scale train to run, my mind turned to how I can use my G Scale locomotives on Gauge 3 track, and then I found this video for inspiration . . .   ;D   https://www.youtube.com/watch?v=VVFk-qHMutU
(https://www.youtube.com/watch?time_continue=11&v=VVFk-qHMutU)

So! getting back to reality and the possible use of dual gauge track (G and G3), and after some re-evaluation of Deltang products by inadvertently watching RC Trains version of the same 'rebranded' Deltang system, and with some co-incidental input from Ralph's 'Cabbage' and Tim Gleed-Owen at the time regarding the building of, and operation of the Deltang radio control system. Additionally, the many thanks I owe to IanT and Gavin's technical posts on this forum, I both read and understood the terminology they were using, and managed to put together a block diagram of 'off-the-shelf' components.


(http://thumb.ibb.co/g6rmRS/BLS_GZ_KLV_7_0_20140109_bobs.png) (http://ibb.co/g6rmRS)


I am now looking forward to testing a potential solution for the integration of 2.4G Radio Control, but also leaving the door open for the consideration of integrating new technology developments such as Bluetooth or Radio distributed DCC (Digital Command Control). A rather nice demo of the Deltang Radio Control system is to be found here . . . https://www.youtube.com/watch?v=dvPks5HAfpQ

The outcome is looking encouraging, as not only is the price of the Chinese based solution cost effective, the whole kit and caboodle (less the brushless motors) comes in cheaper than the cost of a single Revolution Trains 2.4G receiver. And it has the potential to provide far more integration possibilities than the Aristo-Craft Revolution based solution I was looking at previously.


All the components for the bogies,

   
• Bodyshell,
• Chassis design,
• Wheelsets,
• Digital Sound card,
• ESC's,
• Brushless motors and controllers,
• RPM counters and a KMH speedometer

are either on order and/or in the process of being designed, manufactured or delivered. With the Deltang transmitter and receiver to be ordered very soon, the project is well on its way.

The lovely thing about this design architecture, is that with some minor adjustments, the design features can be used for the technically more complicated designs I had for a Revolution controlled 'Peak' and GCR/LNER 8H steam locomotive that I wanted to build.


The ADtranz built 12X is the mothership in a long line of AEG, ADtranz and now Bombardier locomotive developments from which I have a large selection of liveries to consider painting it in.


(http://thumb.ibb.co/jub36S/Re485_Liveries.png) (http://ibb.co/jub36S)

The model will have the following features:

   
• Deltang 2.4G Radio Control
• Manually operated acceleration and braking profiles
• Distributed Brushless Motor Control
• Slave Motor Controllers
• Servo Operated Pantographs
• Directional Lighting to Swiss (SBB) operating standards
• 16bit (CD quality) Digital Sound Card(s)
• User operated Whistle* and Airhorn sound samples
• Stereo pair of miniature Hi Fi speaker technology
• Optional Distributed 'Bluetooth' DCC Control*
• Optional Centrifugal Clutch Drive System*

Many thanks for all the contributions to encourage me get my finger out and finally have a go.

Best regards,


Bob (Doddy)

Thanks very much Doddy, language I can understand in this thread, for a change!
The RC Trains Tx demo video was very good I thought, to introduce the G3 fraternity to these smaller, dedicated and low cost R/C solutions for model trains.  So much better in my view than aircraft "stick"based systems, but I know that is a personal preference.
Is it true that the Tx mentioned in the video is also available from Micron Radio Control as the Tx22, as are others with differing features?
Regards, Tim

The language you understand is probably better than the filthy language I used to try and get the forums website to get my text into line with the format in the way that I wrote it.  >:(

Deltang operate their sales model through distributors, so you are likely to see the same or similar designations for that range of products through different channels. From my brief look on the Micron Radio Control website, it would appear to be a similar designation to that of other Deltang dealers.

Personally, I like the faceplate that RC Trains has had printed for the transmitter. They also have a lot more information on the products capabilities - especially for controlling trains.

(http://thumb.ibb.co/d0HNkn/IMG_1548_1.jpg) (http://ibb.co/d0HNkn)

I do agree with you about the pleasant ergonomic layout, even if I am a bit shaken by the use of Ralph's British Gas style cooker knobs on his transmitter!  ;D

I know some G3 folk have already moved away from 'Flight' technology Tim - but the first R/C train systems were quite expensive from what I can recall.  The Deltang units seem to be much more reasonably priced though - and I look forward to seeing how your project takes shape Doddy.

We've had the Grandchildren here, so not too much has happened G3-wise in the last day or so...they are delightful (but exhausting).

IanT

Robert!

There is nothing wrong with the Davies 1510 control knob. I always use them on everything that I build!!! Given the supplied squishy rubber  things as supplied a good grip either with fingers or in the case of a guitar pedal - toes is far better. If I had wanted something more bizzare I would have used "chicken head" knobs....

Regards

Ralph

Well, I'm afraid I seem to have "bricked" the Atmega MPU on the ESC – it's probably not completely fried but in practical terms it might as well be. Not only that but I've spent quite a lot of time getting here, so I won't bore everyone with all the rabbit holes I've been down but will try to mention the main ones...

Going back to where I left off last time, when I tried to use the KKMulticopter flash tool it simply wouldn't work. It had worked the evening before but the next day it wouldn't fire up and I couldn't think why. However, I felt it had to be something to do with the Java RTE (and Win10) and I wasted some time looking in that area – I had already figured out Win10 environment variables by then. Finally, reading (again) through the KKM site, I decided to try the 'beta' version of KKM (0.8beta6). So I deleted the official (.77) version and installed the beta – this came up straight away – and had some new features. Although 'beta' it dates back to Dec 2014!

So I then tried to re-flash the Esc with SK-v2015 – and AVRdude seemed to be running OK though most of the process but was unable to verify the new firmware and on checking – it appeared that flash had been filled with Hex 'FF' (e.g. all ones!). However, the error message "Cannot set sck period. Please check for usbasp firmware update" was also appearing in the dialogue. So more time was expended in this area, until I found a reference to a problem with some "eBay" USBasp's having old firmware that didn't recognise AVRDudes speed commands...and of course, I had one of them. More time was spent looking at this, with some folk recommending updating the USBasp firmware and others saying it didn't fix the problem. A lot more time was spent trying to get to the bottom of this and somewhere along the way – things stopped working on the ESC.

My current understanding, is that some 'clone' USBasp's cannot have their speed set by AVRDude and therefore don't work with Atmega devices that use the internal clock (e.g. don't have a faster external clock) and therefore have a (J3) jumper that reduces the USBasp clocking speed. The 30A Esc I have doesn't seem to have an external oscillator, so I guess it's internally clocked. So I fitted the J3 jumper but with no apparent improvement. Unfortunately, the more I looked, the more references to these USBasp causing problems to Atmegas I found – as it seems you can screw their "fuses" with poor flash timing.

I will also add that the Atmel 'socket' tool has caused me some issues, as I'm not sure it hasn't sometimes shifted during use and it also makes it hard to do (other) things when one-handed. Tonight (given an apparently dead chip) I've soldered wires to the pads just in case (without any change).

Before I forget to mention it, during this evening, I also updated my Arduino installation (which also uses JRE) and KKM stopped working again. I had to re-boot the PC to delete the Java folder and re-load Java – but then KKM did come back. So it appears KKM is very twitchy if anything changes in this area...which may have been the problem with v.77 - KKM probably isn't completely happy with Win10 I'd guess...

So, once again it's getting late, too late to really think straight about "what next?" – so I will sleep on it and see how I feel about things tomorrow.     

Regards,

IanT

Having thought further about what to do next, this morning I ordered a replacement 30A SimonK ESC to continue work on. Basically, I feel that having come this far along the 'Option 1' route, it would be a shame not to try to finish this research. I started out ordering four inexpensive BLDC's just a few weeks ago – and really knew nothing about BLDCs, ESCs or all the other technology required to use them.  I'm still no expert by any means but I now know quite a lot more than I did at the beginning of January.

I know that the motors will at least 'spin' and that I can control them with a simple programme. I know that the ESCs have a 'tgy' version (2012) of SimonK flashed on them.  I also understand quite a bit more about the GUI utilities (KKM/BLHeli) that let newbies (like myself) access AVRDUDE easily via Windows 10. I've learned (the hard way) not to try to use a 'cloned' USBasp to programme an Atmega8 chip with just an internal clock available.

So I will explore using another programming device (perhaps the one I should have used in the first place) namely an Arduino with an 'In-System Programmer' sketch loaded on it (Arduino-ISP).  If I can re-flash the ESC, then I think I can improve its start-up & slow speed performance a little – but that may be just enough.  I've looked at the SimonK source and clearly friend Simon knows a great deal more about driving sensor-less BLDCs than I am ever likely to.

The last ESC took about two weeks to arrive, so this one will likely be about the same. In the meantime, I will get an Arduino set-up and ready to go. I'm still looking at the other options but if I can get a basic ESC 'driver' working, then it will be worth doing further work on the mechanical aspects of my design and building the bogies. I can always upgrade the electronics/software once I have a half-useable platform to work with. I'm still not sure whether this will work but if possible I'll not only get my engine running but also be able to provide a workable 'recipe' that others can follow.

Regards,

IanT           

" I'm still not sure whether this will work but if possible I'll not only get my engine running but also be able to provide a workable 'recipe' that others can follow.
Regards,
IanT"

Ian, just make sure the recipe is along the lines of "Jamie's 30-Minute Meals"  :o

Watched his earlier TV series and they were very good - not watched his later stuff. Took the family to the local "Jamies" when it first opened. A complete disaster, we never went back, so I'm not surprised his restaurants are in trouble.

As for BLDC 'recipies', well if someone else had already come up with one - it sure would have saved me some time and trouble. Frankly, I'm always very happy to use other peoples good ideas whenever possible. In reality, I think most folk will be quite happy to continue with Brushed motors, given their relative simplicity. So the number of people here likely to try BLDCs is probably very small - so some assistance may be possible in any 'hard to do' areas... we'll see.

However, my Shildon prototype did in fact use an axle-hung motor set-up (on all four axles) - and they were single geared at just over 4:1 ratio. So it's kind of appealing for me to use BLDCs that are near scale size and gearing, as well as in practice, needing something that will fit and work. I don't know for sure but suspect that the prototype motors probably had a mix of shunt and series windings which were switched in (or out) as required to get the engine moving. However, I don't think I'll find a small version of one of those!   :D     

Regards,

IanT

Well a quite day on the Forum (getting ready for the big match?) - so a (very) quick update on my BLDC project... and just been looking at my last 'report'..

In the event not too much progress was made in this area (although some Arduino programming did occur) as our eldest son (and family) moved back in for several months whilst between house moves. This was followed by nearly a month in Canada and most recently a week up in North Wales. However, I've been stirred from my lethergy by the arrival of an email from Farnell on Wednesday.

Last year, I spent some time looking at alternatives to 'drone' ESCs and found a number of interesting devices, some of which were only available "in commercial quantities" and others which seemed just a bit too complicated for my old grey cells to comprehend. However, there was a new TI device that seemed to fit my needs and Farnell listed it on their website - although no stock was showing. I ticked the box to indicate my interest and basically forgot about it. Over six months have passed but Farnell now have them in stock and I've ordered a sample.

Essentially, it's an ESC on a chip, complete with power drivers and computer interface - and most importantly - it's reversable. On balance I've decided it's worth changing the direction of my project to look at it in more detail and try to get a test bench running using it.

More to follow - been told I've got to go out now...and it is a nice sunny day.   

Regards,

IanT

Well we got back in time for the game and I'm sure everyone is very happy with the result!  :-)

Back to this thread - and I've spent a few days trying to understand how the new TI (Texas Instruments) chip can be used to help solve my problems. This involved reading the spec sheet a few times and trying to imagine what work/knowledge would be required to implement the chip in practice. In essence I've replaced one set of 'problems' with another - but on balance I think it is worth a change in direction (assuming I can get it to work). The 'drone' ESC tech is probably already obsolete and therefore may not be available (from China) for too much longer. It also required a good deal of work to get the full functionality I required. So whilst it's a 'built' solution - it wasn't one that seemed to have a long life when looking forward.

The TI chip is new and will probably be around for a good while but is only a solution at 'component' level - and therefore needs a lot more development at systems level. However it implements the tricky software that drives the 3-phase motor and removes a great deal of complexity at the physical level (which Gavin clearly understands much better than I do). The other approach would be to look for a fully implemented commercial system (which Doddy has done) but I enjoy playing with this stuff and hopefully can find a solution that fits my longer term ambitions.

So - I'll post this intro/update - and then provide some backgroud techie stuff (for anyone interested) in the next post...

Regards,

IanT   

Ok - for those interested in the tech detail (others may look away now!) - the TI chip is the DRV10987. A quick feature summary is as follows:

Motor Operation range -  6.2 V to 28 V
Drive Current: 2-A Continuous Winding Current (3-A Peak)
Sensorless Sinusoidal 180° Commutation Scheme
Configurable Output PWM Slew Rate and Frequency for EMI Management
Initial Position-Detect Algorithm to Avoid BackSpin During Start-Up
No External Sense Resistor Required
Flexible User Interface Options: – including I2C Interface: Access Registers for Command and Feedback
Dedicated SPEED Pin: Accepts Either Analog or PWM Input
Dedicated FG Pin: Provides TACH Feedback – Spin-Up Profile Can Be Customized With EEPROM
Forward-Reverse Control With DIR Pin
Integrated Buck Converter, 5?V, 100-mA
Integrated LDO, 3.3?V, 20-mA
Protection Features – Overcurrent Protection (Phase-to-Phase, Phase-to-GND and Phase-to-VCC Short Circuits
Lock Detection to Detect Rotor Lock Condition
Anti-Voltage Surge (AVS) Protection & Undervoltage Lockout (UVLO)
Overvoltage Protection – Thermal Warning and Shutdown • Thermally Enhanced Package

So in summary - this chip seems to do everything I might need to drive a small BLDC motor and provides some simple ways to control it. Essentially the speed can be directly controlled via a PWM (or Analogue) signal and direction controlled via a single I/O pin or even a simple switch. I had hoped that the I2C comms would let me control multiple motors from one CPU - but it only has a single I2C address, so would need a CPU per DRV/Motor set. However the I2C can be used to configure the internal firmware to tune the DRV to the motor and set things like ramp-up speeds etc. So my current thinking is to use one DRV per motor - with a single MCPU controlling multiple DRV/Motors via seperate PWM 'channels'. I'm more comfortable with this - as I can do this in a high level language that doesn't need to be particually fast and lets me hang other things in there as I develop other facilities.

I will need a PCB to mount these on and have never tried to develop one before - but I'm hoping my friends at MERG (who I know do this stuff routinely) will be able to assist me come up with a basic system. I'm fairly confident that if I can get the basic chip running - that I can come up with the systems to configure and control them...

Enough for tonight  I think...

Regards,

IanT

Well the TI chips have arrived and I was expecting them to be small (from reading the spec sheet) but the actual size knocked me back a bit when I opened the package - they are not just small - they are blooming minute!

I'm going to have to take them to my MERG pals and get some advice with regards working with (e.g. soldering) small Surface Mount Devices - as well as help with PCB design software. Fortunately - I know they can do this. So whilst I'm still excited about the potential of these devices, they are not going to be easy to quickly prototype in quite the same way I'm already used to.

Meanwhile - Ralph is working on his "Brains Onboard" in another thread (using Arduino). As I've already mentioned earlier in this thread - I'm finding Micromite Basic a very useful tool to work with. Apart from writing an 'onboard' control system to drive the DRVs - I also have to write a DRV 'set-up' utiility to write and check the EEPROM settings on the DRVs (to match the BLDC motors being used). This would be quite a task using most 'systems' but fortunately MMBasic supports I2C (the comms protocol required to do it) natively, so it should be much easier. I'll used my MM+ system to do this, as I'm coming to view it as a kind of universal (software) screwdriver. Whilst I write the code on my Laptop, I can also download it with one click - so a bit like an Arduino in that respect. However, I can also edit (and execute) code directly on the PIC chip - so it's very interactive to debug and test (no compile/download/test/edit cycle).

I still intend to use a 28 pin PIC32 (also running MM Basic) for my 'on-board' brains - as it will be quite fast enough and has plenty of memory and I/O for the task. As a cross-platform system MMBasic is very flexible - I have it running on a RPi 3 (with GPIO access) as well as directly on my Laptop (in a DOS Window). There is also a very fast MMB version now available on the STM Nucleo-H73ZI (An ARM 7 based system) but I think the 28-pin PIC is quite good enough for my use - provided of course I can off-load the actual motor drive software elsewhere (which the DRV chip will do for me hopefully).

Anyway - very interesting to see all the different approaches to this challenge - hopefully we can make some progress (albeit in my case - probably slowly).

Regards,

IanT