RG1 1.8v regulator

Hi

I have now done the Troy Mackay fix to my test board, it was not easy to cut that small traces and then solder the wires to the board but with an microscope and time it was done and seems to work.

I have also removed the RG1 and RG2, but i was not lucky with the desoldering of the RG2 as i have damage it and it is no longer working so i am using an replacement LF33CV that i have.

So guys what testes do you like me to do and what IR images, for now i am thinking some things like this.

Test 1

Work: idle

board: as unmodified (execpt i am using the LF33CV as RG2)

Test 2

Work: CPU is calc Pi, taking images from webcam, copy files via network

board: as unmodified (execpt i am using the LF33CV as RG2)

Test 3

Work: Idle

board: replace RG1 and RG2 with switchmode, disconnect the LAN9512 1V8 rail from RG1

Test 4

Work: CPU is calc Pi, taking images from webcam, copy files via network
board: replace RG1 and RG2 with switchmode, disconnect the LAN9512 1V8 rail from RG1

This is the tests i have planned for now, but i will like to hear if your guys like some other ones or changes.
For the tests i have done see the post 40 in this thread http://www.element14.com/community/message/57800#57800

Tooms

Nice job.

Quick tip when you need to do "airwire" mods on small pitch components, instead of using wirewrap or plastic insulated wire, you can use transformer wire that is thinner and also insulated, before soldering you can put a little bit of solder on the tip of the wire which will melt the insulating barnish.

Good source of thin transformer wire, CFL lamps, don't throw them to the garbage, carefully remove the lamp from the socket, you will find a tiny pcb with some components, one of them the switching transformer, you can take it appart and use that wire.

There are many other components on that little board that may be of good recycling use.

BTW, I asume that cutting the trace removed the connection to the caps for the SMSC internal regulator, you need to add the recommended capacitance on those pins to ensure proper operation of the internal regulator.

My .02

-J

Nice job.

Quick tip when you need to do "airwire" mods on small pitch components, instead of using wirewrap or plastic insulated wire, you can use transformer wire that is thinner and also insulated, before soldering you can put a little bit of solder on the tip of the wire which will melt the insulating barnish.

Good source of thin transformer wire, CFL lamps, don't throw them to the garbage, carefully remove the lamp from the socket, you will find a tiny pcb with some components, one of them the switching transformer, you can take it appart and use that wire.

There are many other components on that little board that may be of good recycling use.

BTW, I asume that cutting the trace removed the connection to the caps for the SMSC internal regulator, you need to add the recommended capacitance on those pins to ensure proper operation of the internal regulator.

My .02

-J

jamodio

>Nice job.

Thanks

>Quick tip when you need to do "airwire" mods on small pitch components, instead of using wirewrap

>or plastic insulated wire, you can use transformer wire

yes now you say it, i have hear about the use of the transformer wire but i just forgot it and i was not having any

>BTW, I asume that cutting the trace removed the connection to the caps for the SMSC internal

>regulator, you need to add the recommended capacitance on those pins to ensure proper operation

>of the internal regulator.

i have cut the board traces but not removed the caps and i am thinking of just leave them there as they do no harm.

for the testing i will add the caps there is showing in the SMSC LAN9512 pdf file and not go for what ever values there is on the board now.

Morgaine Dinova

>That's very impressive work Tooms, well done. Your list of tests sounds good.

Thanks

>.....measuring USB data loss....

how can you see there is package loss, is there an log file or ?

Thanks

Tooms

Tooms wrote:

 

>.....measuring USB data loss....

how can you see there is package loss, is there an log file or ?

That's the problem, there doesn't appear to be any way of directly quantifying loss of USB events, AFAIK.  Adding logging to drivers can help somewhat, but it can never be foolproof since if the driver doesn't detect the loss then it cannot log the problem.

This is why I mentioned direct injection of numbered USB packets, for example using a microcontroller board pretending to be a HID device like a mouse or keyboard, which would allow this numbered sequence to be monitored from the Pi end.  Any numbered packet missing from the sequence would then be trivially detectable as lost USB data.

Injecting numbered network packets into Pi's network interface might also help (since network traffic flows over USB in the Pi design), as long as the protocol used is not error-corrected (hence no TCP for example).  UDP or ICMP echo should be usable.  However, as I remarked earlier, network packets may not exhibit the same fault characteristics as HID devices if they use a different USB transfer type.  Network error monitoring is extremely useful of course, but may not provide full coverage as a test method for USB data loss.

Morgaine.

It is not a scientific or elaborated tool, there are other tools that can be used to generate different streams and types of packets, but this one is very simple and available on any linux distro.

If you have another *nix server in your network (has to be preferable in the same segment/switch,) as root you can run the ping program in flood mode, in that mode the machine/interface will try to spit ICMP echo packets as fast as possible, here is an example:

root@tango:/# ping -f -n 10.0.2.60

PING 10.0.2.60 (10.0.2.60) 56(84) bytes of data.

.^

--- 10.0.2.60 ping statistics ---

38799 packets transmitted, 38799 received, 0% packet loss, time 18693ms

rtt min/avg/max/mdev = 0.335/0.439/5.464/0.067 ms, ipg/ewma 0.481/0.444 ms

ping will continue to send packets until you cancel the program with control-C and then will report the statistics in the bottom.

If you start to loose packets or the "echo" packets don't return after a given time (configurable) you will start to see dots filling the screen.

The -f option means flood mode, -n so you don't waste time to resolve the reverse address of the IP address used (that's the fixed IP I assigned to the R-Pi in my lab)

There are other useful options like setting the size of the packet payload, or the pattern, etc, do man ping to have the complete list/description.

With this simple test is how I found and reported that one of the earlier versions of Debian (not Raspbian) was producing a kernel panic, since I switched to Raspbian I have not tried again to see if the problem was fixed on the Debian distro. Didn't have that problem with Arch Linux, and it seems that the panic was related to the USB driver and the ability to handle properly interrupts.

Another example:

root@tango:/# ping -f -n 10.0.2.60 -s 1024

PING 10.0.2.60 (10.0.2.60) 1024(1052) bytes of data.

..........................................................................^C

--- 10.0.2.60 ping statistics ---

25974 packets transmitted, 25900 received, 0% packet loss, time 23598ms

rtt min/avg/max/mdev = 0.739/0.829/5.947/0.080 ms, ipg/ewma 0.908/0.830 ms

In this case you can see that there is no packet loss but given that the payload is larger the R-Pi takes more time to return the echo packet.

You can obviously also ran ping in this mode from the R-Pi:

root@raspberrypi:/# ping -f -n 10.0.2.24

PING 10.0.2.24 (10.0.2.24) 56(84) bytes of data.

.^

--- 10.0.2.24 ping statistics ---

16236 packets transmitted, 16236 received, 0% packet loss, time 11801ms

rtt min/avg/max/mdev = 0.383/0.438/1.365/0.045 ms, pipe 2, ipg/ewma 0.726/0.497 ms

root@raspberrypi:/#

-J

To test character-loss on serial lines I've written a program that's called swirl (IIRC).

abcdefghijklmnopqrstuvwxyzABCDEFGHIJLKLMNOPQRSTUVWXYZ1234567890

bcdefghijklmnopqrstuvwxyzABCDEFGHIJLKLMNOPQRSTUVWXYZ1234567890a

cdefghijklmnopqrstuvwxyzABCDEFGHIJLKLMNOPQRSTUVWXYZ1234567890ab

etc. You can see kilobytes of data pass in front of your eyes, but one byte or packet missing and you'll spot it. But programmatic checking is also possible.

Put this in a teensy or multio http://www.bitwizard.nl/catalog/product_info.php?products_id=56 and you'll have an easy test.

I usually use the ACM class for programs in the multio: I have a virtual com port on both ends, which is convenient.

Reminds me of the "classic" text string for serial communications (you can add the lower case version obviously)

THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG 1234567890

http://en.wikipedia.org/wiki/The_quick_brown_fox_jumps_over_the_lazy_dog

-J