734 replies to this topic

[mjr]

 

The latest version is the one I've built on the repository. The old one is the one I've installed in december 2015 before you start working on the reverse CDD issue.

 

Okay - probably something in the USB updates then.  You've tried the *very* latest?  I did an update about 10 days ago that fixed a compatibility problem that was added in the USB overhaul.

 

 

If I plug with the computer already running it starts ok everytime.

If I turn off and turn it on with the device plugged, i have the red light blinking and need to press the reset button (or unplug / replug) to have the green light.

 

The reliable connection with the computer already running is a good sign, at least.  The USB problems before the overhaul caused that to fail on some machines.

 

When you have the problem after reboot, do you see one short red flash at a time, or two flashes in quick succession?

 

 

Several people fix this issue with the use of an usb hub or USB PCI card. It happens only with the mother board built-in usb port.

 

That's consistent with the nature of these problems.  Empirically, I've observed that there are small differences in the USB protocol implementation from one host chip set to the next.  The mbed USB protocol interpreter is extremely rigid and fragile, so these small variations are enough to cause errors that prevent the initial connection from succeeding.  I've already debugged (and fixed) a few cases that trace to these host chip set variations, so the mbed code is better than it used to be, but I don't think it will ever be perfect because the motherboard manufacturers are constantly revising the hardware on the host side.  Every new motherboard seems to be a new potential conflict.  Hubs and add-in cards can *sometimes* work around these, since those will interpose yet another USB chip set on the host side, and if you're lucky, your hub will use a chip set that the mbed code works with.

 

I'd really like to track down and fix every one of these incompatibilities.  Unfortunately, it's *really* difficult to debug when I don't have the same hardware you're using, because the only way to figure it out is if I can look at the exact USB message exchange on your machine that's causing the problem.  If you're running Windows 8+ or you're using a USB 2 port, I can show you how to set up the Microsoft Message Analyzer (a free developer tool from MSFT) to capture the USB traffic during the connection attempt to a log file, and you can send me the log to look at - I can sometimes figure it out from looking at that.  But your problem is during the initial Windows boot, which makes it almost impossible even to use this technique, because the error has come and gone by the time you can start the message capture tool.

[LeStef31]

No problem for me to help debugging the issue. Yes its the latest, less than 10 days.

 

Unfortunately for the moment I'm on vacation and I'll be back next week.

 

There is an event in the windows event log :

Sorry it's in french but should be understandable..

It says that the device had an issue during the startup..

 

Edited by LeStef31, 26 February 2016 - 08:06 PM.

[mjr]

There is an event in the windows event log :

Sorry it's in french but should be understandable..

It says that the device had an issue during the startup..

 

Yep, that's the generic message for all USB errors, so unfortunately it doesn't tell us anything.  (Isn't that a perfect microcosm of Windows, by the way?  It seems all technical and detailed and sounds like it should tell you something if you just know the secret language, yet it contains no useful information.  In this case it's useless because EVERY error in a USB connection has exactly the same message, no matter what the underlying cause.)

 

The way to debug these is with a tool called Microsoft Message Analyzer.  It captures all of the USB message traffic between device and host.  The USB protocol consists of a long string of control messages, and the connection failure is caused by an error interpreting or responding to one of those messages.  MMA can pinpoint which one is failing, which doesn't tell us what's wrong with the program on the device but at least narrows down where to look.  Unfortunately, I don't think MMA will be helpful debugging your reboot problem, because you have to manually launch it and start a session with it BEFORE the connection error occurs - that's the only way that it can capture the message we're looking for.  With a reboot problem, the connection failure happens while Windows is still booting, so by the time we get to the Windows desktop to launch an MMA session it's already too late.

 

If you're able to reproduce the problem any way other than rebooting, we might be able to use MMA to debug it.

[LeStef31]

Thanks for these instructive explanations.

I will try to reproduce it in a debuggable context.

Thanks for the support.

[vulbas]

Hello,

I can not operate the Tilt.

I tested with two cards and the problem is the same.

I use the last bin.

 

please help me

[mjr]

I can not operate the Tilt.

I tested with two cards and the problem is the same.

I use the last bin.

 

You're talking about the accelerometer nudging, I assume.  

 

Very strange...

 

Maybe it's your VP settings.  Have you tried looking at the joystick readings directly with the Windows control panel?  (Type "set up USB game controllers" into the Start menu search box, select Pinscape Controller, then click Advanced to view the joystick input.)

[kruuth]

I'm having a problem.

 

When I do the configuration it seems to work, however...when I pull back, it hits a certain spot, like 35% and suddenly it spikes up to 95% and then back down accordingly.  Also, when I view the CCD in the test program, it seems like it's working.  Sometimes though when I do this, it crashes the viewer.

 

Do I have a wire crossed some place that would cause the spike or something like that?  

[mjr]

When I do the configuration it seems to work, however...when I pull back, it hits a certain spot, like 35% and suddenly it spikes up to 95% and then back down accordingly.  Also, when I view the CCD in the test program, it seems like it's working.

 

It's hard to tell without more specific data, but my first guess would be that the optical image probably isn't as stable as it needs to be.  When you look at it in the sensor viewer (in the test program), what kind of image quality are you seeing?  The important features are the contrast level between the bright and dark regions, the sharpness of the shadow, and the uniformity of lighting in the bright and dark regions.  If the image looks washed out, try reducing the light source brightness or moving it further away.  If the image looks too dark, try making the light source brighter (moving it closer isn't an ideal solution because that makes the shadow edge fuzzier).  If the shadow edge isn't sharp, making the light source aperture smaller or moving it further away from the sensor should help.

 

If that weird 35%-95% jump occurs at one specific point in the plunger travel, look at what's going on in the sensor viewer when you move the plunger to that position and see if there's some kind of glitch visible in the image.  Maybe you're getting a reflection or there's a wire casting an extra shadow there or something.

 

If none of that helps or you're not sure how to interpret the image in those terms, make a video of the sensor viewer and post it so I can take a look.

 

Do I have a wire crossed some place that would cause the spike or something like that?  

 

I'd consider that unlikely, given that it's working at all.  If you had a wiring problem you probably wouldn't be able to get a usable image.  

 

The exception would be if the plunger is physically coming into contact with one of the wires as it moves.  That could be jiggling a loose connection in the wiring, which would certainly cause problems in the data quality.

 

There could also be electrical noise problems coming from a high-power feedback device like a solenoid.  If the glitch is plainly correlated with a solenoid firing, I would suspect that.  If there's no obvious correlation like that, I'd look elsewhere.

Edited by mjr, 29 March 2016 - 03:57 AM.

[kruuth]

I'll take a video of it.  Problem is when I view the slide it normally crashes the program for some reason(?).

[kruuth]

OK here's a picture of my lights:

 

 

Keep in mind that the wires are behind the lights and the sensor.  I had to stick my hand in there to get that.  Here's the link to the video I made showing what it looks like:

 

https://www.youtube....h?v=kyYBL0qQ39U

[mjr]

OK here's a picture of my lights:

 

 

Keep in mind that the wires are behind the lights and the sensor.  I had to stick my hand in there to get that.  Here's the link to the video I made showing what it looks like:

 

https://www.youtube....h?v=kyYBL0qQ39U

 

Okay, you clearly need to adjust the lighting.  What you *should* be seeing on the sensor view is a uniform dark region and a uniform light region, with one nice sharp edge separating them.  You have alternating bright and dark stripes.  The plunger position is determined by where the edge is between the dark and light regions, so as you can see from the view on your sensor, it's completely unclear to the software where that one sharp edge is because there are many dark-light-dark-light stripes.  The reason the plunger position seems to be jumping around randomly is that the software is continually guessing which of the many edges is the right one.

 

I can't see from the picture what sort of light source you're using, and of course it's impossible to tell from a photo what the absolute light level is, but it looks to me like the light source is probably too bright and has too wide an aperture.  The multiple stripes in the sensor view could just be coming from the excessive amount of light on the sensor, or they might be reflections.

 

My recommendation for a light source is a single 20mA LED, since that's easy to set up and is a nice small point source.  You might also be able to adjust your existing light source by putting a hood or mask around it - maybe try a piece of cardboard or thick paper with a small (1-2mm) hole.

Edited by mjr, 29 March 2016 - 06:24 PM.

[kruuth]

Ok that makes sense.  Right now I'm using a pair of 12v bayonet LED bulbs with 5 LEDs on them.  I added them because I thought I had too little light.  I can easily dim it. 

 

What kind of power do I need for a 20mA led?

[mjr]

Ok that makes sense.  Right now I'm using a pair of 12v bayonet LED bulbs with 5 LEDs on them.  I added them because I thought I had too little light.  I can easily dim it. 

 

The easiest thing to try first would just be reducing it to a single one of those bulbs you're using now.  That might help by reducing the spread of the light source.  The wide source area is probably spreading out the shadow quite a lot because you have light coming at the sensor from many directions.  You could also try the masking trick I mentioned earlier, although I personally found it easier to just use a smaller bulb.  When I was first setting this up, I didn't know how much light it would take, so I tried one of those 350mA star LEDs.  That turned out to be massively more light than needed.  These sensors are pretty amazingly sensitive and don't need much light.

 

 

What kind of power do I need for a 20mA led?

 

Those just need a 5V power supply with a current-limiting resistor.  Use a calculator like this one to figure the resistor size you need once you have your LED picked out:  http://led.linear1.org/led.wiz

Edited by mjr, 29 March 2016 - 10:35 PM.

[kruuth]

Ok, I dropped the illumination way down with some parts I have laying around.  Now the image looks like this in the video:

 

https://youtu.be/3TU8zYrn3ww

 

However, it's still very, very jumpy.  Do I need to drop the lighting more?

[mjr]

Ok, I dropped the illumination way down with some parts I have laying around.  Now the image looks like this in the video:

 

https://youtu.be/3TU8zYrn3ww

 

However, it's still very, very jumpy.  Do I need to drop the lighting more?

 

Hmm... all I see is solid black now, so I think you might have reduced it too much.  But it might only be lack of contrast in the video; can you see any contrast at all when you look at it in person?

To reiterate, what you want to see is a nice uniform light region on one side, a nice uniform dark region on the other side, and a nice sharp boundary between them.  It doesn't all have to be perfectly black and perfectly white - shades of gray are fine, but it's important for there to be clear contrast and uniformity and a sharp boundary.  When you move the plunger, you should see the boundary with the plunger.

[kruuth]

I have a pretty clear boundary or so I thought.  I'll try adding a little more light.  What about the jumpyness?

Ok, I slightly increased the light.  Same thing.  I have a pretty clear boundary but I am getting a few "bands" of black as I pull the plunger down.  There's black and grey.  What should I do?

[mjr]

I have a pretty clear boundary or so I thought.  I'll try adding a little more light.  What about the jumpyness?

 

If it's jumpy, it's because the boundary isn't clear to the software.  There has to be one sharp edge.  If you see multiple bands of light and dark, the software is going to get confused because it can't tell which band is the real shadow and which bands are just noise.  If the contrast is too low, the software won't be able to find the edge at all.

 

Your last video looked pretty solid black to me, but like I said, that could just be the video quality.

[kruuth]

No there are some pretty solid black but thin bands.  Should I use brighter light or move the source closer?

[mjr]

No there are some pretty solid black but thin bands.  Should I use brighter light or move the source closer?

 

I wouldn't move the source closer - that's usually bad because it makes the shadow fuzzier.

 

Maybe you could do another video at a better angle so I could see better - all I can tell you from the last one is that it looked like solid black, which makes me think you don't have enough light now.  When you make the video, be sure to SLOWLY pull the plunger back through its entire travel range so I can see what kind of image you're getting at each point throughout the travel.

[kruuth]

Ok here's another video.  Hopefully this is better.

 

https://youtu.be/eDiEHYrZfPQ

 

I moved the connection wires away from it and that seemed to fix it a little, but I've noticed that the ball will just shoot off the plunger, even before I pull it back.  Is there some number I can edit to fix that?