RS have been the only one still buying from me. You should have a look at their stock.

Manufacturing is done in batches of 2500. As sales have been declining, it is not economic
viable for me to start a new batch. (I sold ~400 last year). I still have a few hundred in stock
but I am not set-up to e.g. sell them on ebay. Too much hassle with packaging, payment, shipment etc.

I just did the following:
Downloaded the GUI 2.8
Downloaded the gb_upload program.
Connected a gertbot version 2.7
Uploaded version 2.8 to the board.
Started the GUI.
Selected Step Gray Pwr.
Kept the Frequency at 100.
Set the ramp start/stop as 1
Set the ramp speed as 0.1
Set 10000 steps.
Start the stepper motor.
For me it works. Where did you encounter problems?

RS have been the only one still buying from me. You should have a look at their stock.

Manufacturing is done in batches of 2500. As sales have been declining, it is not economic
viable for me to start a new batch. (I sold ~400 last year). I still have a few hundred in stock
but I am not set-up to e.g. sell them on ebay. Too much hassle with packaging, payment, shipment etc.

They only have 123 left, and they won't ship to the US. If you stop manufacturing the GertBot's, would you consider releasing the source code for the firmware or even the board layout?

I searched here, if there is a similar problem, but I didn't find this specific error message.

Next I wanted to update the board with a new firmware version (2.8).
- Downloaded the gb_upload.exe and the latest firmware as described in the download sequence.
- If I run the executable, then a window opens (Main window) with two active buttons "connect" and "exit" and two inactive buttons "upload" and "download" (greyed out) as well as an empty field.
- I can't do any action with it...pressing "connect" or "exit" shows no reaction. Closing the window results into the message "The window "Main Window" does not seem to be responding..."

I think there is simply a communication failure with the board...maybe something very easy, if it can be found?!

that would have been too easy...however I first read a bit in the manual and your website about how to get it working...the basic things like enabling the UART are done...maybe not correctly? I'll double check and come back.

Hello again,
the only issue left was the wrong board address in the python script. After a second connect with the gb_upload executable I could see that it's addressed with board 3 by default (why not 0?)...however,
my board is now doing the tests well after a few corrections in the python script (e.g. you wrote somewhere that one should start with a low frequency...the move_stepper test starts with 5kHz, which gives only a noise without moving the motor...my stepper runs with up to 900 Hz).

so for me with Jessie on a Pi3 the following lines work for enabling the serial communication with the board:

enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250

Finally I can start programming my application.

Thank you very much Gert for this very functional board (I appreciate the end switches and the higher frequency than the adafruit board)!

Hello Gert,
thanks very much for the „Gertbot“ which gives me the opportunity to run model trains with a RPI A+ via Wifi (WLAN0). Unfortunately I killed up to now two gertbots and I hope, You can help me to reanimate them.
What I did: I put the gertbot (Vers. 2.6) on a rpi A+ and connected two dc-brushed motors (24V, 1A) in parallel to channel 0. I wrote a c-program (modified copy of the “Rover” (thanks for that nice program)). I enabled the uart-interface and everything went well. The supply voltage was 23 V, the current about 1.8 A. the supply voltage is generated by a rectifier (6 A) stabilized by a capacitor of 170 mF (gold caps).
After a few minutes running the model train stopped and the led D7 was fast blinking. So I thought something went wrong. I took the gertbot out of the train and connected it to an other rpi A+ in my test lab. An equivalent other dc brushed motor (24V, 1 A) was connected to channel 0 and an external power supply with 20 V DC. The gertbot GUI showed “Enable 0 was negated”. So I tried Your recommendation with the ramp-up and ramp-down option. No result.

Next I tried to reset the gertbot by shortening pin 6 with pin 7 on J10. Fast blinking of D7 stopped but no result (D8 normal heart beat blinking).

Then I renewed the image with gb_upload (rmc_2.6.crypt) successfully but no result. So I connected the two brush motors on channel 1. The model train run for a few minutes and again the same break down as on channel 0.
Channel 2 and 3 I killed by putting the wrong polarity of the supply voltage (V+ to Gnd, Gnd to V+, my fault).

Next step was to connect to the second gertbot each dc brushed motor to channel 0 and channel 1. I modified the c-program by doubling all motor program lines but change only the channel from 0 to 1. Everything worked fine. During the endurance test after about 10 minutes on the track channel 0 stopped while channel 1 was still running.

Same procedure as described above without any result.

So I did additionally the ./gtest -t3 (move brushed motors). A warning came up “make sure that short/hot has been disabled!!” But how to do this? I did not found it in the different gertbot manuals.
Again I reconnected the model train now to channel 2 and 3. Everything looked perfect in the test lab. But during the endurance test, both motors stopped at the same time after about 5 minutes. Same procedure , described above but this time, no fast blinking of D7 (D8 regular heart beat blinking). No error code (Board 3 ; No error) without any result.

Before I will kill further gertbots I would like to ask You for help, how to avoid the damages.
Thank You in advance for Your answer.

I have to work through your text in detail and think about what may be happening.
I have thus far, (keep fingers crossed) not been able to blow up a board other then by a too high voltage
on the motor connector. I have run test with directly shorted outputs.

The ramp-up and will only prevent the 'Enable-x ' error during starting as it reduces the in-rush current.
If the error happens after a few minutes somehow your motor(s) draw a too much current whilst running.

As to the fast blinking LED: it disappears when there are no more errors in the report queue.
Thus you have to read the errors, which are in a short FIFO.

Gert,
Thanks for the fast reply.
In the second endurance test I forgot to tell, that I only run the duty cycle by 75% and in the first test at 100%. As there was really only the locomotive running, a too high current seems to me not the root cause, as I understood the specification right, each channel cane drive 2.5 A. Even if I put a very high load on the motor, the current does not exceed 1.2 A.

The strange thing to me is, that it happened in a stable situation, far away from any specification limits (30 V, 2,5 A).

The problem is that the hardware and CPU are very, very fast.
Even a very short current spike may trigger the stop-mode.
Command <0x21 <id> 0x00> will prevent that.
Thus 0x21 0x00 0x00 for channel 0,
0x21 0x01 0x00 for channel 1 etc.

It does NOT disable the short circuit protection. That is always enabled.
All it does, is tell the CPU to ignore any short-circuit pulses and keep the system running.

What duty cycle frequency are you using?
A very low frequency may be seen as continuous start-stop.
In fact that was the way I tested overheating:
big motor 50% duty cycle, 10 Hz. PWM.

Hello Gert,
this seems to me possible. I know this Problem with the very fast CPU from Counters, which also count the Spikes.
But it cannot be the current spike, because the current in an inductivity (coil) is not able to jump! It is the voltage that causes the Spikes. If You disconnect an inductivity it wants to continue the current and when you force it to do so it answers with high voltage spikes. This happens in every DC brushed Motor, because the coil of the rotor is forced to be disconnected by the Rotation of the rotor. At bigger DC brushed Motors (>1 kW) you can see the firing.
So the cpu detects the voltage spikes (not current spikes!). So I have to suppress the voltage Spikes by a capacity. I have to look up how to calculate the Dimension of that capacity.
As I understood the H-Bridges are driven by MOS-FET's, which are very sensitiv to voltage Spikes (thats why You should always work with ESC protection) so I guess the Output of the gertbots are dead, because they do not run when I connect them to the GUI. You think so as well or how I can make sure, that they are really dead?

I will connect an Oszilloskop to the Output of the Gertbot and perhaps I can see the Spikes.
As I am a bad programer, will You please tell me, how the command line You mentioned looks like in a c-program? Where do I have to place this line? After / before every move-declaration?

the built-in freewheel diode is mandatory to switch the directions. The spikes I am talking about are coming from the commutator on the rotor, which Switches the coils on the rotor of the brushed motor. Unfortunately I was not able to see them on the oscilloscope, because it is a very old analog one.

If it would be the very fast CPU that triggers the stop mode, the motor should run again after a new initialisation, but it doesn't.

During the tests (with the GUI, one motor) with the last channel available it happened, that one direction failed (Enable 1 was negated) so that I only can run one direction on this last channel. All others channels are dead as described.

Thanks for the set_short command. I will use it when the problem is solved for the next gertbot.

I'm currently working on a proect that requires me to use the Gertboard to control a servo on which a camera will be fixed. However, in your latest installment of the manual, very little is said about this mode, and not much more can be understood through your Python / C code commenting. So I'm gonna ask out my questions here:
- Is it possible to put a servomotor within the channel that normally uses brush motors (as your manual indicates page 30)?
- If so, how can we control it using your Python commands? Are there any installed in Python code?
- If we use the pins that you indicate on photo page 25 what data are we to send on it?

I hope I didn't come out crude or anything but I am genuinely stuck at this part, and may have some frustration due to this issue. Hope you won't think ill of it.

The latest manual (version 2.8) has a chapter (10) dedicated to servo control. It also states that there are no driver routines yet.

I apologize for that but due to circumstances, I do not have access, nor had access for the last year, to my electronics equipment.
The firmware running on the gertbot was written and tested before that.

- Is it possible to put a servomotor within the channel that normally uses brush motors (as your manual indicates page 30)?

A channel can work either as servo or as brushed. Not both at the same time. The reason is that they use the same timer configured as a PWM generator.

- If so, how can we control it using your Python commands? Are there any installed in Python code?

As mentioned there are no C or Python driver. I can write some code and post it, but there is no way for me to test it. My experience has taught me that "unless it is tested, it will not work." If you have a look at the python drivers, all calls are more or less the same: It takes the function arguments and convert them into bytes to send out. The gertbot GUI has controls for Servos. You can bring up your system with that. You can also see the exact command bytes it generates in the log window.

- If we use the pins that you indicate on photo page 25 what data are we to send on it?

You do not exactly send commands to the pins. You send commands to the gertbot MCU and it will generate servo pulses as per chapter 10 in the document. The MCU will also 'correct' your values to cope with the Servo trim parameters.

No, that was not crude it was a genuine valid question addressing some of the, unfortunate, flaws there are in dealing with servos at the moment.

I will write some Python Servo code in the next 48 hours and post it on the gertbot website. As stated it will be untested, thus it may not work first time. You can either fix it yourself, or tell me what is wrong an I will try to fix it.

The latest manual (version 2.8) has a chapter (10) dedicated to servo control. It also states that there are no driver routines yet.

I apologize for that but due to circumstances, I do not have access, nor had access for the last year, to my electronics equipment.
The firmware running on the gertbot was written and tested before that.

- Is it possible to put a servomotor within the channel that normally uses brush motors (as your manual indicates page 30)?

A channel can work either as servo or as brushed. Not both at the same time. The reason is that they use the same timer configured as a PWM generator. Beware that they use totally different pins!

- If so, how can we control it using your Python commands? Are there any installed in Python code?

As mentioned there are no C or Python driver. I can write some code and post it, but there is no way for me to test it. My experience has taught me that "unless it is tested, it will not work." If you have a look at the python drivers, all calls are more or less the same: It takes the function arguments and convert them into bytes to send out. The gertbot GUI has controls for Servos. You can bring up your system with that. You can also see the exact command bytes it generates in the log window.

- If we use the pins that you indicate on photo page 25 what data are we to send on it?

You do not exactly send commands to the pins. You send commands to the gertbot MCU and it will generate servo pulses as per chapter 10 in the document. The MCU will also 'correct' your values to cope with the Servo trim parameters.

No, that was not crude it was a genuine valid question addressing some of the, unfortunate, flaws there are in dealing with servos at the moment.

I will write some Python Servo code in the next 48 hours and post it on the gertbot website. As stated it will be untested, thus it may not work first time. You can either fix it yourself, or tell me what is wrong an I will try to fix it.

The latest manual (version 2.8) has a chapter (10) dedicated to servo control. It also states that there are no driver routines yet.

I apologize for that but due to circumstances, I do not have access, nor had access for the last year, to my electronics equipment.
The firmware running on the gertbot was written and tested before that.

- Is it possible to put a servomotor within the channel that normally uses brush motors (as your manual indicates page 30)?

A channel can work either as servo or as brushed. Not both at the same time. The reason is that they use the same timer configured as a PWM generator. Beware that they use totally different pins!

- If so, how can we control it using your Python commands? Are there any installed in Python code?

As mentioned there are no C or Python driver. I can write some code and post it, but there is no way for me to test it. My experience has taught me that "unless it is tested, it will not work." If you have a look at the python drivers, all calls are more or less the same: It takes the function arguments and convert them into bytes to send out. The gertbot GUI has controls for Servos. You can bring up your system with that. You can also see the exact command bytes it generates in the log window.

- If we use the pins that you indicate on photo page 25 what data are we to send on it?

You do not exactly send commands to the pins. You send commands to the gertbot MCU and it will generate servo pulses as per chapter 10 in the document. The MCU will also 'correct' your values to cope with the Servo trim parameters.

No, that was not crude it was a genuine valid question addressing some of the, unfortunate, flaws there are in dealing with servos at the moment.

I will write some Python Servo code in the next 48 hours and post it on the gertbot website. As stated it will be untested, thus it may not work first time. You can either fix it yourself, or tell me what is wrong an I will try to fix it.

The issue, as I forgot to mention, is that I'm trying to not use the GUI as the final product is to be totally autonomous, where the inputs for your commands would be given through EKFs, and so, I was trying to not use it. If you recommend using it at first so I can get familiar with its construction, I'll abide.

Secondly, along with my team, we are trying to use a native Python coding, so that all of our programs could run on it. If you were to provide with a solution, could it be that you make it using Python coding? it would be much appreciated.

Also, if we try to come up with a solution of our own, the function writing would come across as sending Something along the lines of os.write(0xA0|0x27|"bytes of specifiation")? Such as commands that you've already written? (and operation mode for said servo would be 0xA0 0x01 <id> 0x03 0x50?)

I mentioned the GUI only to get you started and test the HW. You are probably going to need it anyway to find the servo 'trim' values.
Being used to accuracies of 1% or even 0.1% I was some what surprised to see that the servo position deviations where in the order of 30%

As of a few minutes ago there is an alpha release of python drivers with support for servos. The code has been run on a Pi but I have no actual servos available for testing: https://www.gertbot.com/download.html