Problems with Hub AP5 module

Hi to all members of this community:

I’ve started a new project with .NET Gadgeteer and I planned to use the Hub AP5 Module to control a 4 Relays (Y Shocket), a Motor Driver L298 (P Shocket) and a OneWire X1 (XY Shocket) modules connected to a Spider mainboard.

I’ve had a lot of problems with Motor and OneWire modules only when connected to the Hub AP5.

In the case of OneWire X1 Module it send a initialization error and in the Motor Driver module, it doesn’t regulates properly the motor power (don’t work under 50% values and when put 100% value in code, actually it only reacher an 70% equivalent power output -I’ve analyzed it with a O’scope-).

I’m using MF 4.2 and the last stable versions of Gadgeteer and GHI SDK and Firmware/Tiny Booter.

I think it has trouble managing interrupts but don’t know how to manage and solve this problem.

Any ideas?

Thanks a lot!!

I know this needs better clarification but you can’t use virtual sockets with one wire, no hub basically. The good news is that you need a single free pin to use one wire devices.

As for the motor control, this can be resolved but we need a bit more info please.

Welcome to the community.

@ Gus - Thanks for the OneWire and Hub (virtual sockets) explanation I didn’t know that before.

In order to bring to you more info about the Motor Controller + Hub AP5 problem, I managed two scenarios:

[ol]The first one with Motor controller directly attached to the mainboard, that as you can see in the attached image but it was the minimum configuration as possible.

The second one with Motor Controller attached to the Hub AP5 and this to the mainboard. Also detailed in the second screen capture from the VS designer. [/ol]

The code remains untouched in both cases:

            int time = 2000;
            MotorControllerL298.Motor testMotor = MotorControllerL298.Motor.Motor1;
            while (true)

                motorControllerL298.MoveMotor(testMotor, 0);

                motorControllerL298.MoveMotor(testMotor, 25);
                motorControllerL298.MoveMotor(testMotor, 50);
                motorControllerL298.MoveMotor(testMotor, 75);
                motorControllerL298.MoveMotor(testMotor, 100);

I’ve captured the signals of the motor output with a oscilloscope and the results were absolutely different showing a complete loose of motor control in the second scenario.
No current pass to the motor until you are above 25% and it don’t increment power above 75% of power even if code sais it could be 100%.

I’ve tested it with two different Hub AP5 modules and also with two different MotorController modules so it is very difficult that the problem was a fail in the modules hardware.

If you need more information I could try to obtain more data in order to make the system working correctly.

Thanks a lot for your excellent support!!

you probably need to tell us what each scope capture represents

Sorry Brett, I’m a novice in the forum and I made the mistake of type the meaning in the file name (which evidently is loosed in the presentation!).

Now I typed the conditions “inside” each scope capture.

You can see that all works perfectly (duty-cycle OL) in the direct connection but strangely when HUB AP5 is involved (except for 0% of power which works like a charm!! :wink: )

Thanks a lot

@ magustin - the problem is that the default clock source we use for the chip on the hub is inadequate for higher PWM frequencies that require more precise duty cycle resolution like the motor controller. In fact, at the 25KHz frequency that the motor controller uses, the chip only allows around 0%, 33%, 66%, and 100% duty cycles, which is what you see. The driver does not currently support using the other available clock sources to generate the signal, but it’s something we’ll look into it.

That said, you can manually add the driver for the Hub AP5 to your project and switch to a different clock source as a work around. You’ll want to reference the datasheet for the chip, it’s the CY8C9560A chip from Cypress. Take a look at the Period, Pulse Width, and PWM Clock Sources registers on page 13. You’ll see that we are using 93.65KHz in the driver. The 1.5MHz clock will give you 60 duty cycles (0%, 1.666%, 3.333%, 5%, 6.666%, …) when using the 25KHz frequency in the motor controller. If you change to that clock, you should have better control.

@ John -

That explains the abnormal behavior that I saw!
Now I can take corrective measures in my project.
Thank you so mach!!!