FluxFocus

OK, This has nothing to do with electronics unless you count the rocket igniter control box. But it was fun. We had no idea what we were doing to begin with but quickly learnt as we lost rockets.

 

Australias biggest horse race is the Melbourne Cup. It's a state holiday in Victoria. Elsewhere in the country we might have a lunch, a bet and maybe wear our finest or silliest outfit. I had the idea of making a motorized novelty race themed hat. I kind of only thought about it during the afternoon before the race day.

I ran around to Altronics and grabbed a hobby motor and a battery holder. I put together a circuit to slow the motor down some. We had some cardboard at the office and Mum gave me use her collection of paints. The hat was well received by my colleagues during our Melbourne Cup lunch.

 

We, that is to mean I and my colleagues think that windows XP has a bug. I'd be interested to hear from anyone who can convince me that what we are seeing is expected operation. I would post the wireshark log but it gives away too much info.

So, ever come accross this scenario? a client trys to connect to a TCP server but encounters an out of place ACK from the server:

---------------------------------------------------------------

0ms:               Client:         Gratuitous ARP

29ms:             Client:         TCP SYN

62ms:             Server:       ARP broadcast whois this client? tell server!

250ms           Client:         TCP SYN      - retry. last SYN timed out.

509.64ms      Client:        ARP tell response to servers whois  <- some latency issue

509.65ms      Server:      TCP ACK   - <-what the hell is this? out of place ACK.

544ms           Client:        TCP RST,ACK     <- client didn't like that last response

1519.26ms   Client:         Gratuitous ARP    -session retry begins after some time

1519.27ms   Client:         TCP SYN

1519.30ms   Server:       TCP SYN,ACK     <- works 'cos server now has fresh ARP

1521ms         Client:        TCP ACK          -three way handshake complete

     And the session continues normally from here on.

-----------------------------------------------------------------

So what went on there? I think winsock gets confused about the ARP response coming in just after the SYN retry. Incidentally I can recreate the fault often if i continually delete the server's ARP table.

One might look at this and say "Who cares? it gets through on the second try right?". Maybe for some applications, but for realtime applications, this delay is absolutely unwanted especially if the client invlolves some human interaction. Think battery operated wi-fi applications. And on the other hand it's windows winsock and it should be held to higher standards blah blah blah roll your eyes at me.

The fault is triggered by some latency and we had seen it happen on one brand of wi-fi infrastructure and not another. When it worked ok, it was because the ARP was not mysteriously delayed so long that the client decided to send another SYN.

The device would have probably gotten through on the second SYN try if not for the odd response from the server. Also, it appears, having tested only Windows XP and Windows 7 that the odd response fault is present in XP winsock but appears to have been rectified in Windows 7 winsock.

For connections from the same client that reoccur frequently,  this might not be so much of a problem since the ARP entries will still be in the server and get refreshed. But for clients that connect once in a while, the ARP entry will have timed out on the server when they go to connect and the fault will reoccur.

 

OK, so I've come along a little ways since the last video about what I'm doing this. The first iteration of fibreglass came in and I've populated. I still wasn't sure about a few things with the design that I had started with so I knew there were going to be issues with this iteration of fibreglass. One of my main challenges with this circuit is to have close to 50ohm output impedance at the BNC connector.

Making this an even more interesting challenge was my decision, as a techinical challenge, to use only 2n2222 transistors in the rf sections. The clapp colpitts arrangement I decided to use for the oscillator has an output impedance high enough that some consideration had to be given to downstream component selection. I successfully manged to route the signal through a common collector transistor arrangement and then on to a voltage divider biased final stage whose collector load was a matching transformer I had roughly hand wound to try to produce ~ 270ohm:50ohm impedance transformation which seemed to work quite well.

My other big challenge here was the modulation transformer. The supply side of the matching transformer is fed by a modulation transformer, again of my own rough calculations and rough hand winding. I figure it is about 32ohm:50ohm at the sort of  audio frequencies you might expect, or there abouts. Apparently it's unusual to wind a modulation transformer on a toroid. I'm not quite sure why yet. It did take some time. Winding multiwinding toroids is pretty boring and its almost impossible to keep neat windings. As evidenced in the video it seems to work out well enough though.

If my next iteration of this circuit is more stable and successful, I'll try to document it. Also, I'd prefer the audio source to be simpler, and on the same board rather than requiring an external source. However it needs to be something recognisable, preferably some simple repeating tune. I had thought of those melody ICs but the output waveforms are very square. I'd prefer something more sinusoidal. I may have to make that an iteration beyond the next one. For the next iteration, I'd be happy if it just looked neater with components of correct value in their correct spots. not sure about the variable resistors. I might put two footprints on in parrallel.

This video is just the process i was using to remove some j lead PLC chips off their driver PCBs and replace them using solder paste and a heat gun. Sorry about the audio quality in this video. I did this on my phone camera and the audio is a bit sketchy.

Here's a quick overview of a project I've been fiddling with and considering for a while. The idea is to have an oscillator I can use to align the tuning dial for some AM broadcast receiver projects I am workiong on and would like to work on.

Some of this experiment is about to migrate to a manufactured PCB. On the next version there will be three seperate oscillator circuits rather than switching components in and out of a single oscillator circuit.

So, I've been helping a friend out with his recalcitrant CNC machine. One of the axis was really playing up. And we discovered that one of the lines from the octal latch on the printer port receiver PCB was a bit dodgey. We suspect the octal latch, a 74HC244 to have gone cactus.

 

I started out to do a quick video about my "poor tech's method" of removing SOICs but decided to also show how I was going to replace the SOIC narrow IC with a SOIC wide IC.

 

Here in this video I'm voicing my frustrations about vendor provided mechanical dimension diagrams that don't transalte well to creating footprints in ECAD software like EagleCAD which is what I currently use.

So the TG-K4AT programming software for that family of radios has an option to change the frequency range. The interface asks for a password.

Under the Machine menu there is an option Machine Info. This brings up a dialog box titled Model Information.

 

 

 

 

A button here is titled Change Fre meaning Change Frequency Range. Clicking the button then prompts for a password. The password you need to enter here is: TGK42009   

I've been playing around with a lot of different toroid cores for the purposes of tuning coils, filters and transformers mostly for rf applications. I thought I'd do a little overview of a few cores, how they differ and why you might use one instead of another.