Problems with Hub AP5

Archive
1

I have a hub which I have been using for some time with no problems.

Today I reconnected it through a Power Extender Module since I was getting worried about my 5V draw.

After that it still ran, but very very very very slowly. The delay is happening even before my ProgramSTarted is called and so I get a string of warnings about initialization time exceeding up to 130 seconds.

So I disconnected everything from the hub except for a 3 module string of multicolor LED modules which had been working great.

Again, I could control the LEDs but very slowly (like 2 minutes or more to blink them one time each).

So I disconnected the LED string from the hub and connected directly to the main board. Everything works fine.

I violated the do one thing and check it runs. I also was working on some code for I2C sensors at the same time. I did run some of the code once, and it crashed. I know the Hub uses i2c so I have now completely removed all my i2c code (not just not running it, removed from the project).

Have I some how fried the hub? If so, how so that it still runs, but so slowly. Did I reset some I2C parameter somewhere in the Hub or main board that has it set to very low speed? I looked at the Hub driver code and could not see anything I could have overwritten.

I don’t have a second hub to swap out.

Any advice would be welcome.

2

@ Duncan - Does the slowness persist even if you remove the power extender?

3

@ John - Yes, first thing I did when I was trying to troubleshoot

4

@ Duncan - Do you have a logic analyzer by any chance?

5

@ John - I do and putting it on the i2c lines to see what is going on is on my list of tasks. I need this to get the other i2c devices I have going anyway. It will be a few days before I get to that task. I’ll post what I find when I do.

6

I was searching to forums to see if anyone else had this issue, and I came across this thread.
I have this exact same problem.

The multicolorLEDs when connected to the AP5 Hub take unbelievably long to initialize, or to set the color (1.5 minutes to initialize)

It eventually works, but I cant really use LEDs that take [em]minutes [/em]to initialize or set a color.

Using it on the Mainboard (fez raptor), they work fine, instantaneously. Just not on the Hub :frowning:

All I have is a USB Client DP power module (Socket 8) the AP5 Hub (Socket 12) and 3 Multicolor LEDs linked and on hub Socket H6.

If i just have 1 LED on H6, it still takes forever.

But this is a bare configuration - no other I2c devices anywhere. It couldnt be simpler.

Just to initialize the 3 LEDs takes 90 seconds:

Using mainboard GHI Electronics FEZ Raptor version 1.0
WARN: Total initialization time exceeds 10 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 20 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 30 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 40 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 50 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 60 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 70 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 80 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
WARN: Total initialization time exceeds 90 seconds.
    : ProgramStarted is blocking execution, which means events and timers will not run properly.
    : Make sure not to use blocking code such as while(true) - use a GT.Timer instead.
Program Started

And then a another minute just to execute the following 3 lines:

            Debug.Print("Program Started");

           multicolorLED.TurnBlue();
           multicolorLED2.TurnGreen();
           multicolorLED3.TurnRed();

Is there a basic incompatibility between the hub and the multicolorLED modules?

I am using Netmf 4.3, but Ive also tried 4.2 (same issue)

7

@ mtylerjr - The MultiColorLed module uses DaisyLink internally, which uses software I2C. Since the hub is an indirected module, bitbanging I2C over it will be very slow, as you saw. The only fix is to use the module on the mainboard and leave the hub for tasks that don’t need quick I/O, like a simple switch toggle.

8

Thanks John.

That makes sense.

I wish, though, that there had been a note in the product description that would indicate that any module connected to the hub would be an order of magnitude slower.

I just bought about $650 worth of product from GHI to build some robotics devices… I was counting on those additional P sockets, but they aren’t (as you say) usable for anything real-time. I will have to get creative, I guess (not necessarily a bad thing)

I’m just disappointed in it. I would return the Hub and trade it in for a Cerbuino Bee or another n18 display module or something, though, if return shipping from New Zealand wasn’t so expensive :frowning:

9

Maybe we can help you in figuring it out. Tell us more about what your address trying to build and what timing is needed please.

10

@ mtylerjr - the PWM might be just fine, the chip on the Hub app will drive the PWM, so all you would be sending over I2C for PWM is the configuration after that it will be native to the chip.

11

Thanks Gus and taylorza

To be honest, I don’t have a very specific end-goal in mind. I’ve mounted the Raptor on a smart-car/robotics chassis driven by 4 motors. I intended to use the Motor Driver L298 module to drive the motors (the two left motors on one channel, and the two right on the other)

I was then planning to use the other PWM pins on the Hub sockets to drive other servors… standard stuff… ping sensor rotation, grippers, pan/tilt camera, etc.

This was going to be connected to an android phone app, driving the thing through the wifi module (would have preferred bluetooth, but the bluetooth module has been discontinued)

I’ve done all this previously with parallax Boebots, and arduino based platforms, but the 400Mhz raptor got me excited again. (Thus the $650 splurge during the holiday sales, lol)
As a former Microsoft employee, I’ve always liked the NetMF

So, in addition to the motors, I was intending to drive 5 or 6 other servos. Thus the interest in the Hub , since the raptor has just the one P socket, which has all 4 PWM channels used by the L298 module.

I am still waiting for some servos to arrive, but I am concerned that it will take 90 seconds to trigger a servo to move, like it took to light the multicolor led module. If PWM on the hub is reasonable, then I can continue. If not, maybe I’ll look to graft in an arduino dedicated just to the servos (and my Easy VR voice recognition shield)

This is really just a learning platform to share with my 9 year old son

How speedy do you think it would be to use PWM on the Hub to turn a standard servo? I had intended a ping"sweep", turn the servo a couple degrees, get a reading from the Ping Sensor, turn another couple of degrees, etc. On something like the parallax stamp board, a 180 degree sweep like this would take 5-10 seconds, depending on how small the increment.

Im just wondering if this is an unreasonable expectation using the PWM on the hub. I would be sending a stream of PWM servo orientations=, each a few degrees more turned, with just the time for a ping result in between.

Would the hub PWM be fast enough for that?

12

How many PWM pins do you need? What mainboard are you using? Do you realize the Cerbs have 11 or 12 PWM pins?

EDIT: Disregard most of this… You answered the mainboard question in your previous post while I was typing :slight_smile:

1 Like
13

@ mtylerjr - PWM speed will not be your problem. Like I mentioned previously the only thing conveyed over the I2C protocol is the PWM configuration i.e. the frequency and duty, the rest is all carried out by the chip.

What is going to be a problem is actually achieving low servo frequencies with the standard driver, actually it will be impossible I think. I have not looked at the data sheet for the chip. but I suspect it will not be too much of a challenge to bring the code for the Hub AP5 driver into your project and select an appropriate clock on the chip and customize the drive to support the lower frequencies.

The chip is a CY8C9560A from Cypress if you decide to give this a try.

Attached is a capture from my board generating a 5Khz signal and toggling between a 50% and about 16.5% duty cycle. So definitely no problem with the speed.

1 Like
14

Thanks. I will give it a try.

I did find a little Pololu 6-Channel Servo Controller in my box of random unused parts… I may just use a com port on the raptor to drive servos through the tiny controller instead.

15

Okay, I’m back to ask questions about the HubAP5 module.

I have add very strange issues with it… essentially I can’t predict what will work, and what wont.

My character display module -will- work on some of the Hub sockets (H8) but will not work on others. Actually, it even depends on which I socket the hub is using. On some combinations it will work, on others I get a “SoftwareI2C: Exception writing to device at address 32 - perhaps device is not responding or not plugged in.”

The Tunes module, while it works fine on a main raptor socket, it either fails to work at all on some Hub sockets (total silence), or it “works” somewhat on others, but the pitch/tone of the notes is completely off (some of the standard “notes” get shifted to only-dogs-can-really-hear-them.

I get the “Software I2C” vs hardware problem - but it still baffles me why a “p” module like the tunes module will behave very differently even between different Hub “p” sockets, or a “y” module like the character display will behave very differently even between different Hub “y” sockets - I would assume we would be comparing apples and apples (both software I2c)

Is there a list somewhere of these known idiosyncrasies? I see others talk about them in other posts going back months/years.

Is there a list of which modules work with the hub, and which don’t?

I need to control 4 independent motors, and I intended to use two motor driver modules - which requires use of two of the hub’s P sockets. I have not received both yet, so I don’t know if the motor driver module is one that will work, or will have the same sort of issues.

And, if the motor driver module is not compatible with the hub, is there a common work around that others have come up with (using the raptor) ?

And lastly, is there some sort of pattern, where I can look at a hub socket schematic, and say “okay, clearly a P/Y/A module wont work in -this- P/Y/A socket, but it will work in -this- one” since it seems I can’t just go by the socket letter/designation?

16

@ mtylerjr - The CharacterDisplay will probably always give you trouble. It is very sensitive to timings and the chip the HubAP5 uses is very slow for GPIO. Your best bet is to not use it on the hub.

Can you by any chance scope the PWM pin to see what sort of frequency and duty cycle you do get when compared to what you expect? What range of frequencies are you setting?

Doing a quick look through of our modules, the only others that could give you an issue on the Hub are the PulseCount and RotaryEncoder since they use software SPI and any DaisyLink module since they use software I2C. Modules like the BreakoutTB10 or LEDStrip will work, but will not be able to toggle anywhere near as fast as a native GPIO could.

1 Like
17

Hi John,

Unfortunately I don’t have a scope with me (mine is in storage in California for whenever I go back to the US) so I cant give any scope readings…

But clearly there is some sort of basic issue here, I would think.

I got around to using the motor driver module on the hub, and it [em]mostly [/em]works - except, like the tunes module, things are “shifted” to different frequencies - the motors operate at different speeds when the motor driver module is connected to the hub, compared to when connected directly to the raptor.

…And they arent "symmetrical:…That is to say, when the driver module is connected directly, setting a motor speed to 1.0 is the same speed as -1.0 (only in the other direction)

When connected through the hub, this is not the case - I can get the motors to spin in both directions, but the range of speeds in one direction is not the same as the range of speeds in the other. if I set one to 1.0 and the other to -1.0, one spins fast, and one spins slowly.

I would assume on first glance that this is the same thing that is going on with the tunes module, where the standard “MusicalNote” enum values match the correct notes when the tunes module is connected directly, but are bizarrely shifted in tone when connected through the hub (didnt anyone test this combination before the hub was released?)

I don’t have a scope, but it “seems” clear IMHO that the Hub is causing connected modules to generate incorrect PWM frequencies.

The good news is, that at least I -can- get motors to spin in both directions. I will just have to put in some “fudging coefficients” and live with the motors not having the same range of speed in both directions.

I do wish someone would find the root cause and either make a patch, or at least note this issue on the product web pages. I see posts of people saying “I just saw the hub! 5 more P sockets” and I know they are going to run into the same issues.

I havent tried using the hub with other boards like the hydra+ or spider.

18

@ mtylerjr - I would suggest 2 things to try

  1. Drop the frequency from the default 25kHz down to 5kHz, the motor driver has a Frequency property.
  2. Do not exceed about 0.85 for the speed factor in either direction

Testing with the logic analyzer showed that the PWM signal is a mess at the default frequency. There also seems to be a minimum duty cycle after which the PWM signal just drops to 0. I did not read the data sheet for the chip on the Hub Ap, so I just did a few basic tests to derive the 0.85 as a safe value.

The frequency range is probably a factor of the default clock selected for the IO chip on the Hub AP, again looking at the data sheet and the Hub Ap driver code would give a more accurate indication of the actual range you could use.

I did a very quick test with a motor driver and a cheepo hobby motor I had lying around and the above seemed to work. And of course the least scientific part of my test was that the motor sounded and felt like it went about the same speed in either direction while at 10kHz for example there was a distinct difference and at the default 25kHz it did not work well at all.

I would be interested to hear if this helps at all, since my tests were very simplistic.

2 Likes
19

taylorza!

Changing the freequency to 5000 (5khz) did indeed make a difference!

The motors work great now… predictably, and equal in both directions. I’m back in business!

SO I need to use one frequency for a mainboard socket, and a different one for a hub socket? I can live with that.

Is this a big issue though? Should there be a big warning in the documentation, or am I overacting?

In any case, THANKS GUYS

20

@ mtylerjr - I am glad that helped. I took a quick look at the data sheet for the IO chip and it’s PWM capabilities are rather restrictive IMHO, so I agree there should probably be mention of the restrictions in the docs.

You can of course use the same 5kHz frequency on the mainboard as well, it should work just fine.