Tip to eliminate the pauses and stuttering motion when running from pronterface via USB

[Ezra Zygmuntowicz]

I've discovered a very nice tip that I should have thought of long ago to help eliminate the stuttering and pauses that you get when printing via USB from Pronterface directly. If you do two small things you will get very improved performance without any pauses or stuttering and it will behave basically like it does when printing from sd card.

1. uncheck the "Monitor Printer" checkbox

2. Click the "Mini Mode" button after you have gotten your print started.

After trying to pinpoint why the pauses and stuttering happened over USB is caused by starvation of the GCODE buffer between pronterface and marlin firmware running on the electronics. This happens because the GCODE preview that pronterface tries to keep updated in real tiume can starve the program so it spends all its CPUI time trying to draw GCODE previews and not keeping the GCODE buffer over USB filled with info for the printer to use for motion> So the printer stutters or pauses when it isd starved for information about what to do.

Not saying this is the solution to all freezes and pauses via USB but this is a huge help and you shoudl all try this if you print via USB and Pronterface. It made a huge difference for me and I feel somewhat idiotic for not doing this sooner ;)

Ezra

[John D]

It's not - just had a freeze of my own, and I use Repetier host with preview disabled, etc.  Somethings causing a hickup - host is still waiting on an OK back from the firmware...

[Jean-François Talbot]

Something struck me today about this problem while I was re-installing an ole' laptop.

Would anyone with the freeze problem, within Windows, look under Control Panel -> Power Options

If you are not running the "High Performance" profile, use the change plan setting to select such plan.

Then, within that plan, use the "Change advance power settings" to get to this dialog:

Please make sure Windows will not turn the power off your USB ports if it deems it needs to to conserve power.

It may help.

Jeff

[J S]

Thanks Jean, I think that may have been why my print just died an hour in!

[Jean-François Talbot]

If that did the trick, let us know.

We will add that to the wiki....

[J S]

I think it may have helped, but didn't solve the problem. I just lost it about 90% of the way through a 12 minute print. It didn't die immediately this time or the last... Just changed to one command every 20/30 seconds or so... So I don't know if that is it. My LCD didn't seem to get corrupted this time though.

Wonder what it is? It's a random thing too - doesn't seem to be from running too many programs or hard prints or anything...

[Jean-François Talbot]

Can't help more than that for now as I don't have mine yet.

With Windows, its hard to tell when some process is running. You could have a virus scan starting, you could have defrag starting, you could have some other process like acrobat trying to run its auto-update thing, flash auto update, god forbid, a trojan you are not aware of, well, you get the idea.

I have installed a machine, a small shuttle toaster like shoebox, and there is nothing on that machine, besides the pronterface, arduino ide and the torrino driver. Of course, I installed sketchup, meshlab and few other things, but none are containing any auto-updater and if they did, they are disabled. So, my box is closed to be a bare naked Windows.

We will see when I start printing. Of course, I also made sure I have a descent shielded USB cable with 2 ferrite module, one on each end. The ferrite are from the factory, and non added as a clip-on later on the cable.

Jeff

[John D]

Guys - I'm running my A1 slower than my Ordbots - by a pretty fair amount at the moment - and I simply do not have any problems with long prints on the Ords.  If i use the exact same laptop on the A1, I end up with a hung print about 1 time in 8.  In my mind at least this eliminates the PC as the source of the problem...

I've just gotten back to London, and will be re-assembling the A1 tomorrow, and was planning on running shielded & twisted wires for the motors to see if that makes any measurable difference....

[Jean-François Talbot]

I ordred 1 meter long shielded reprap discount just in case I want to replace the endstop cables.

Lets hope TL worked something out about the next batch. If not, there will be more of us with this problem.

Ezra was saying it occured on others printers as well. Could it be the taurrino playing gt ames with us, wbich would explain John's comment about not having the problem on his ordbot....

--
You received this message because you are subscribed to a topic in the Google Groups "trinitylabs-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/trinitylabs-talk/8e75_kQxLXo/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to trinitylabs-ta...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[J S]

Great, tell us what you find! 

But about my specs: I'm running a not particularly short (but not long, 6 ft?) usb cable to my printer from my semi-super computer (ya, it was great with 8 gb of ram and 6 cores a year and a half ago!), and randomly doing other things on my computer at the same time. I haven't had it hang while watching a movie and doing 5 other things, but it hung while relatively little was going on. I think it did hang once b/c of the usb falling asleep... Anyway, just wanted to queue people in about my irresponsibility. I will probably be much more careful when prints go 2+ hours.

[Colt D. Majkrzak]

This machine is running 12x4.04Ghz cores, 16GB of Ram, and 6x128GB SSD on a LSI SSD controller.  Clearly speed is not an issue with this machine, nor do I get interrupts with my MM1.5, its something to do with the electronics on A1.  I’ve just been printing via SD card w/o issues, but clearly its not the cable, pc, etc.  I can literally move the USB cable to the MM1.5 and print via USB all day long.

 

If I had to guess, its some issue with taurrino, even though it’s the exact same windows driver as the Ardunio 2560 mega.

 

 

 

Best regards,

Colt Majkrzak  F5CI, F5SE

www.newerastreaming.com

www.bitbucketsolutions.com

--
You received this message because you are subscribed to the Google Groups "trinitylabs-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trinitylabs-ta...@googlegroups.com.

[John Stevenson]

You can have the fastest computer on the planet, but the USB port and it's speed is the same as a $300 computer :) So many things can interrupt a USB stream.....

I use a smooth stepper board with my CNC Mill because the parallel ports were just too problematic to spit out a smooth stream. This board handles the input from the USB and then spits out the stream independent of the computer. Just a comparison. I had to do this on an i3 computer with 4 gigs of ram and Win 7 with nothing else being used. It is dedicated to the CNC, in fact it is built into the CNC.

 

I know nothing of these printers yet, but it seems like they need an on board controller to take the usb stream and buffer it and spit it out cleaner or something.....kind of like what the sd card reader does, but without you having to use an sd card and just connecting the USB.  

[Greg L.]

Yes, a local RAM buffer would be /hugely/ helpful - and if and when Smoothie gets 'good', it can have one without too much effort (and will need one if we want the Ethernet port to work right). Essentially, what we need is what Netflix does with the movies we watch - wait until we've got a good 30 second lead time on Gcode from the PC before we start printing, and if the 'seconds of buffer remaining' ever gets below 1 second, drop the max velocity and acceleration in firmware so that the print slows down a bit before the buffer completely drains. A 64KB buffer gets you pretty far towards this goal, but the Arduino Mega used in RAMPS has 8KB of RAM - so that's not going to happen without Smoothie. You /could/ write code to buffer using the SDCard itself, but I'm not sure I'd want to bother writing more code for a deprecated platform.

I've got a USB protocol analyzer in my lab, which is between Philadelphia and Baltimore, so if anyone has an A1 in this region and wants to stop in, I can put the wires on the scope and protocol analyzer and watch the corruption go by for you.

[Ken]

Hi Greg,

Just as some additional data. I'm using an ASUS netbook running openSUSE 12.3 to drive my A1. I haven't done a lot of printing yet (longest was about 90 minutes), but that silly little thing seems to keep up. I watch the system load on a remote display and it never seems to go much above 10%. I don't monitor anything on the pronterface UI, I just push print.

Ken

[Ezra Zygmuntowicz]

Anecdotal evidence points to the taurino power being the core or cause of the issue. Other bots setup with taurino power have the same issues so we are working furiously on debugging this issue as well as the MOSFET issue and will give a status report in the next few days.

As far as second batch shipping status, 80 units began construction at out contract manufacturer in Monday and will be picked up late this week or on the weekend so they can be brought back to Portland and shipped next week.

Out of these 80 units only 40 if them are presales units and the other 49 are not sold yet. Meanwhile here in Portland we've been wiring in parallel on pre assembling the Garry's and extruders and all plastic parts are cleaned and no brim and in general this batch will be much more polished and preassembled then the first batch based on all the great feedback from the list.

So that's what up all back orders will have shipped by end of next week and we are introducing new Alumjnatus sales in 2 new forms tonight or tomorrow.

One of them is an Alumjnatus pro turnkey fully assembled and calibrated with all highest end components and true SIMO stages and all the waterjet cut aluminum cover plates and truss plates.

The pro will be 100% turnkey with a 1 year premium support contract and XYZ parts replacement warrantee. Plus will have all the bells and whistles and some that have yet to be seen even. The new pro turnkey Aluminatus is going to cost $3599.

The second form Aluminatus with be all kit form. It will be the same tslot frame except the z axis will be 200mm instead of 345mm but XY will remain same size as pro Aluminatus. The linear motion stages are new invention of ours code named TRIMO stages as they use same 10 start 25mm pitch anti lash nuts leadscrews but use printed motor and idler mounts and low profile unified slider mounted to 20x60 tslot.

These will provide the same accuracy and resolution as the pro version but the kit is a box of parts with great documentation and will have zero pre assembly. The kit also does not include the waterjet cut aluminum cover plates by default and has. Few less bells and whistles but is still and get nice printer.

The Aluminatus kit with retail for $1599 in order to remain an affordable option and the waterjet aluminum cover and truss plates will be available as an add on option. The kit form is fully upgrade able to a pro version piece by piece over time but allows us to keep a low cost entry point for the DIY crown and a high end turnkey pro for that market segment.

40 units of each the new pro form and kit form will go up for sale this week with 4 week or less lead time from day of payment.

And we already have a big head start on the 40 printers if each type so the 4 week lead time is at the outside and the kit form especially may be delivered sooner but 4 weeks from time if payment if the date promised.

Second batch of prepaid Alumjnatus will all be shipped by next week and I think people will be very happy with the many improvements and the much more assembled gantry, extruder , quality of printed parts and many other improvements.

So there is the update as of this time. I will make a top level post with this info shortly.

I'm stoked on all the feedback and hardworking that has gone into this new batch and I think those of you who waited it out are going to be extremely pleased with your new v 1.1 Aluminatus printers.

And I think the first round limited edition pro and kit versions full out both ends of the market nicely. So stay tuned for more info in all of this soon!

Thanks

Ezra

[John D]

Good to hear Ezra - I ran a ~3hour print job last night, and had the dreaded endstop triggers despite have the endstops set for homing only in Marlin.  I've not looked at the code yet, but something smells there.

Couple of observations - the current Marlin version you have has max and min endstops defined, despite the fact we are using min only - not sure if this makes a big difference, but I did disable the max's.

I also am moving from NO to NC endstops, and will be running a shielded cable.  Since I've got to crimp new ends, I'll be dropping a 4k7 resistor and 1nF cap on the RAMPS end for good measure.

Worse come to worse I have an X3 board lying around that I think can handle 36v - I've send Roy a message to confirm...

To unsubscribe from this group and stop receiving emails from it, send an email to trinitylabs-talk+unsubscribe@googlegroups.com.

[Greg L.]

Ken -

  The limiting factor is generally not your CPU, but the tight communications line between them - the USB/Serial line. At 'only' 115200 baud, you get only 11KB/sec through the line. Given that each character of a .gco is a byte, and each line roughly 16 Bytes (approx) that's about 700 lines per second, best case. Seems like a lot, but if you're moving at 100mm/sec, doing a curve, you get 'only' 7 line segments per mm, with no extruder commands or other overhead involved (and there's always extruder commands and such). 

And that's assuming that the things are perfectly synced. Worse, your printer has an onboard (tiny) buffer, of roughly 16B (if I recall correctly) - which means that the PC can't send another line until the first one has been taken out of the buffer. If the PC gets bored of waiting (after all, it's not hard to send data), it can quickly task-switch to something else, which generally takes at least 5ms to get back (on Windows), meaning you've just fell behind by 3 line segments, and have to catch up. It's not bad if you're doing long straight lines - but for heavy tight curves, you simply never catch up, and your print head just sits there for a minute, oozing, and potentially making a blob in your tight corner, ruining your screw fit (a personal problem I've had on USB/Serial). At that point, ball screws and belts be danged, you're simply not putting the head in the right place, and  your tolerances are wasted.

So yeah - it's not the CPU at all, but the communication line. Going to a 'true' USB can/would help,  as would going ethernet, as would a buffer. All of the above can't be done on an Arduino Mega, however. (Ok, the buffer could, but it would be a pain, and might overtax the Arduino anyway)

- Greg

[John Stevenson]

My Smooth Stepper controller board for my CNC runs off the ethernet port instead of USB.....maybe the printer community should think about this approach rather than USB?

[Jon Bondy]

Is there anything useful here?  I'm not sure.

https://groups.google.com/forum/?fromgroups=#!topic/solidoodle/aW0n2ml42yo

[John D]

John - Sanguinoloulou does not isolate the 5v line from the 7805 regulator on the board from the 5v supply from the computer - the reference circuit for the Arduino Mega does.

[Dave]

On Friday, March 29, 2013 10:27:33 PM UTC-5, Ezra Zygmuntowicz wrote:

I've discovered a very nice tip that I should have thought of long ago to help eliminate the stuttering and pauses that you get when printing via USB from Pronterface directly. If you do two small things you will get very improved performance without any pauses or stuttering and it will behave basically like it does when printing from sd card.

1. uncheck the "Monitor Printer" checkbox

2. Click the "Mini Mode" button after you have gotten your print started.

Is it just me, or does anyone else notice that these options are missing in Pronterface?   My Linux version copy does not have either one present. 

And I just had a print die about 30 minutes in. 

Dave

[BusyBotz]

I have those 2 options, in OS X.

-Mitch

[Jean-François Talbot]

So if it died on you in unix, and some reported the same in OS/X and we know about windows, then, it is definitively the Taurrino Power board.

Too bad the Arduino Due runs at 3v instead of 5v, which makes it not compatible with the actual RAMPS.

J

[Ed DeBoer]

Has there been any progress on this? My A1 just froze at 85% way through a 3 hour print....UGH.

I'm using pronterface/slicr/ and quality USB cable on my Mac.  

[Glenn Beer]

In the windows task manager, processes can be given a higher priority. Wonder if raising the priority of pronterface would help?

[Triffid Hunter]

On 3 April 2013 23:03, Greg L. <greg...@gmail.com> wrote:

Ken -

  The limiting factor is generally not your CPU, but the tight communications line between them - the USB/Serial line. At 'only' 115200 baud, you get only 11KB/sec through the line. Given that each character of a .gco is a byte, and each line roughly 16 Bytes (approx) that's about 700 lines per second, best case. Seems like a lot, but if you're moving at 100mm/sec, doing a curve, you get 'only' 7 line segments per mm, with no extruder commands or other overhead involved (and there's always extruder commands and such). 

And that's assuming that the things are perfectly synced. Worse, your printer has an onboard (tiny) buffer, of roughly 16B (if I recall correctly) - which means that the PC can't send another line until the first one has been taken out of the buffer. If the PC gets bored of waiting (after all, it's not hard to send data), it can quickly task-switch to something else, which generally takes at least 5ms to get back (on Windows), meaning you've just fell behind by 3 line segments, and have to catch up. It's not bad if you're doing long straight lines - but for heavy tight curves, you simply never catch up, and your print head just sits there for a minute, oozing, and potentially making a blob in your tight corner, ruining your screw fit (a personal problem I've had on USB/Serial). At that point, ball screws and belts be danged, you're simply not putting the head in the right place, and  your tolerances are wasted.

So yeah - it's not the CPU at all, but the communication line. Going to a 'true' USB can/would help,  as would going ethernet, as would a buffer. All of the above can't be done on an Arduino Mega, however. (Ok, the buffer could, but it would be a pain, and might overtax the Arduino anyway)

The actual situation is a little different, let me elaborate :)

The baudrate is not the limiting factor of the communication link. USB is a token and packet protocol. The host must issue a token to a device before the device can send data. Our current gcode protocol requires a response line after each line sent. This means that the time it takes to send a line is two round-trip delays plus processing delay on each end. This makes the actual max transfer rate slower than the baud rate due to how USB works. If you want to see this in action, download a gcode to the SD card using pronterface- it'll be quite a bit slower than 11k/s!

However, the firmware buffer is larger than 16b- it's closer to 16-24 full lines of gcode. It requests new gcode from the host whenever there's room in the buffer. Also, there's a planner queue which buffers at least a couple of moves. This gives plenty of room for the firmware to buffer through tight curves. If you want to see how long the buffer is, press pause in pronterface.

I find that 2 segments per mm is ample for smooth curves. That's sufficient resolution for the facets to disappear quite completely. If your models create more dense curves than this, you're burning precious bandwidth for no gain whatsoever. When working in openscad, simply put $fa=0.01; $fs=0.5; at the top of your file for 0.5mm segments.


We have direct USB with smoothie. It also experiences segment pausing when using the standard gcode protocol so obviously the baud rate isn't at issue. If instead we use something like cat gcode > /dev/Smoothie then we have no such issues as the kernel itself holds several kilobytes worth of buffer, and fills every usb packet with the maximum 64 bytes. USB has built-in flow control, so there's no chance of over-running anything this way. The only problem is, if you cancel the print it takes a LONG time to pause due to the huge buffers involved! Perhaps using dd bs=64 would be better than cat? requires experimentation... I intend to write a protocol extension for deferred ack which resembles tcp windowing soon, to get the best of both worlds! :)

[Greg Link]

Triffid -

  First off, yay! Technical discussion!

  Having said that, the TCP windowing solution seems like a good idea, and may help immensely. If you're particularly worried about the pause issue, there might be a way to enable another endpoint on the USB for sideband communication, for things such as estops, temp changes, and pauses. Alternately, simply changing the current gcode protocol is another possibility, but one less friendly to the various open source solutions out there currently.

  To be honest, I was expecting that the Ethernet port on Smoothie would address most of these issues, as you'll (by necessity) need and have bigger buffers and a higher overall communication rate, plus the advantage of automatic TCP/IP packetizing and windowing. 

  Finally, for my own knowledge - you mention a 16-24 gcode line buffer in 'the' firmware. Are you referring to Smoothie, or Marlin/RAMPS? 

[Jon Bondy]

I remain puzzled, since I have used USB to control my printers and have NEVER had the problems that I hear regarding the A1.  My impression is that something else is going on.

[John D]

Two distinct issues i think Jon - one is that the Taurino board that's in the A1 seems to have some problems with locking up and it's usb in general. To me that's completely different from the issue of stalling sending gcode to Marlin.  That i can do on any printer.,..

[Jean-François Talbot]

Problems you have been hearing, are not bound only to the A1.

Ezra's ex-partners that have a printer in beta also have the same complaints in their forums.

Its bound to be the torrino board that causes the problem. The A1 uses the taurrino because it is powered by 24v power supply.

Downgrade them, change heater, and use a regular arduino board, and there would not be any more problems.

Jeff

[Triffid Hunter]

On 18 April 2013 21:09, Greg Link <greg...@gmail.com> wrote:

Triffid -

  First off, yay! Technical discussion!

  Having said that, the TCP windowing solution seems like a good idea, and may help immensely. If you're particularly worried about the pause issue, there might be a way to enable another endpoint on the USB for sideband communication, for things such as estops, temp changes, and pauses. Alternately, simply changing the current gcode protocol is another possibility, but one less friendly to the various open source solutions out there currently.

smoothie already has a config option to provide a second usb serial port

  To be honest, I was expecting that the Ethernet port on Smoothie would address most of these issues, as you'll (by necessity) need and have bigger buffers and a higher overall communication rate, plus the advantage of automatic TCP/IP packetizing and windowing. 

  Finally, for my own knowledge - you mention a 16-24 gcode line buffer in 'the' firmware. Are you referring to Smoothie, or Marlin/RAMPS? 

both. we're working on expanding smoothie's buffer

[UKchris]

Regarding the 'stopping'; In two months of A1 use, I didn't get a single stop - until I moved it.  Due to the inner-moose in it and the bedroom next to it becoming occupied - it had to move.  Difference being that in its new location it shared a power outlet!  So there it was, 80% into a long print and I foolishly switched on the second of the joint power outlets (only a very small transformer) A1 stops at that instant.  Coincidence - maybe, but others have quoted similar experiences.  Don't have time until Sunday, when I will repeat the experiment.  If it does i again, I'm following Jeff's good advice and replacing it with a regular Arduino and a 24-12VDC converter (removing D1 from RAMPS)

Regards

[Jon Bondy]

Are you implying that the power supplies are inadequate?  A decent supply would maintain power in this situation, and would filter any spikes that came along from the "mains".

[John D]

They are cheap as chips Chinese power supplies, but no, there's something in the Aurdino / RAMPS design that makes them sensitive to noise.  All of my Ordbots run on HP DL380 or 540 power supplies, and have the same sort of opposition to other things on the same circuit - no clue why...

[Cozmic Ray]

USB reset
USB reset occurs for any number of reasons
power surge on USB power supply
drawing more than 500ma on USB hub
Cheap power supply on USB or PC
device inserted/removed from USB hub

One of my PC systems bonks (USB device installed/removed) when
I turn on a cheap florescent light plugged into same power strip
as computer and USB hub supplies.  Back EMF from cheap
light power supply surges main power.  Other high power devices
also do the same.

High Power Heaters on A1 very close to USB supply
All very close on crapadino controller

Solution plug in (isolate) sensitive devices away from high power/surgey devices
A typical surge protector doesn't help against this  --- would have
to use device to eliminate dip or surge  (ie auto transformer -- power supply
with heavy filtering /smoothing)

[John D]

Hmm, I generally don't power my RAMPS setups with USB power - and I'm pretty sure I've had a failure printing from SD without a computer connected - we really don't do that much anymore...

[Ed DeBoer]

For kicks, I purchased a 3' Gold plated USB cable from Monster Cable.  Its supposedly the best cable on the market.  Still had same results.  I died around 80% completion in a 3 hour print.  UGHHH

[Glenn Beer]

Try running the USB cable the shortest distance out from under the printer. Then to a computer on that side.

[Jon Bondy]

I have been following a Mendel Max 2 Beta thread entitled "Printing stops randomly with an "o"".  The latest posting is this:

"I can confirm it is the Taurino board, I pulled mine, put a mega 2560 in and cut the D1.  It communicates just fine and doesn't freeze up.  cheap easy work around so you don't have to pull your hair out.."

How many of the A1s are being run over USB?  How many have had to resort to an SD card because the USB connection was not reliable?

[Rick Zehr]

I've been running mine from Pronterface, and when it printed, loading the gcode file from the SD card, but my results have been just the opposite: I've had little problem via USB, but the LCD spazzes out and goes random at frequent intervals. 

The only way out of the LCD going crazy is to remove and replace the SD card, and then, if printing at the time, Resume Print from the LCD menu.

[Dave]

On Saturday, May 4, 2013 6:58:55 PM UTC-5, Jon Bondy wrote:

How many of the A1s are being run over USB?  How many have had to resort to an SD card because the USB connection was not reliable?

I am running all my prints from the SD card.  I think I lost 4 or 5 prints before giving up.  My LCD works fine, and USB communication via Pronterface is also fine for mid-print temperature adjustment and the like.  No dropped prints off the card. 

Dave

[Jon Bondy]

This from the Mendel Max 2.0 Beta forum:

Hi all,

A fix came through from bubblerap the person behind reprapdiscount where the tuarino boards are from.  You need a uart connector to flash your card, but it is supposed to stop this issue

https://www.dropbox.com/s/xb0djxuwd2g9tp3/16u2.zip

[Glenn Beer]

I built the harness to try this using a second arduino mega. Haven't had time to actually flash it yet. 

[Steamer]

Flashed it, and so far it seems to have fixed the problem for me, still testing though.

Emile

[John D]

So far so good - I used an ISP to do mine, and HUGE thanks to Emile for coming up with a great testing methodology!!!!!

[temo]

Hello

 

Any step by step guide for this to us that are not into electronic and what uart connector can one use(link?)

 

Terje

[Sean Mitchell]

Do you have an extra arduino around?  In the zip file it details how to use a second mega 2560 to program the original one:
http://images.wikia.com/qmast/images/d/df/8u2ISP.png

I think any arduino shoud work if you don't have a 2560, as long as it has SPI (and the pins would of course change which you can look up on arduino.cc).  Arduino also has documentation how you do this here (but the wiring diagram is wrong, the wiring diagram shows how you program the main chip (2560 in your case) -- you want to program the smaller chip that sits between the 2560 and the USB port, use the wiring diagram provdied in the zip file).

If no extra arduino is available, my friend just bought one of these to do his RUMBA, still waiting for it to arrive though:
http://www.ebay.com/itm/USB-ISP-Programmer-for-ATMEL-AVR-51-ATMega-ATTiny-/200460739146

--
You received this message because you are subscribed to the Google Groups "trinitylabs-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trinitylabs-ta...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

========
Sean Mitchell

echo "zvgp...@tznvy.pbz" | tr '[a-m][n-z][A-M][N-Z]' '[n-z][a-m][N-Z][A-M]'

[Triffid Hunter]

https://picasaweb.google.com/lh/photo/JsS8LqIfbWS6Tx7eYuutNNMTjNZETYmyPJy0liipFm0
is my ISP programmer :)

[John Stevenson]

Funny you link to that thing on eBay, because I just got an e-mail from Hobby king out of the blue with this in it....

http://www.hobbyking.com/hobbyking/store/__27990__USBasp_AVR_Programming_Device_for_ATMEL_proccessors.html?utm_campaign=150513.USE&utm_content=131386532&utm_medium=email&utm_source=EDM

$3.95