Bryant's network control/measuring PDUs

http://www.bryant-unlimited.co.uk/eyepower.html

My good pal Simon Quill at Bryant has been developing this line of intelligent bay mains distribution for the last few years and I bought a couple last year and have (due to the weight of work) only just got around to playing with them. Quite a lot of manufacturers offer remotely controllable power strips with either a bit of client software or a web interface to control the various circuits. Some even offer current monitoring (typically via a shunt-resistor so you get apparent current; the heating effect, in effect!) but Bryant claims to actually measure the current via a clamp-inductor and they calibrate each circuit's 16-bit ADC prior to it leaving the factory. Simon tells me each circuit can measure to 50A to an accuracy of 1mA and they sample at 1Khz so you can see any harmonic content that is being put on by UPSes etc. 

Some of the other features;

1. Macro start-up, close sequence. You can (for example) get o/p 2 to hold off powering up until o/p 1 has settled.
2. Control of each circuit via the web interface - re-power that server?
3. Inspect the current draw (and power factory) on a per circuit basis; worried that an array of disks is starting to show odd consumption; maybe a drive is about to fail?
4. Look at the quality of the incoming mains - it's rarely a sine wave nowadays!

Simon & I intend to do an episode of The Engineer's Bench on IP controlled PDUs (not just these Bryant ones) but until then here are some screen-grabs.

 This one shows the graph for the third circuit which has an AlicePak audio balancing interface attached and is (we hope!) a linear supply and hence should be an entirely resistive load.

 This is my trusty Tektronix WFM7120 which is clearly using a switch-mode supply; notice how the current draw is when the driver transistor switches as the voltage passes a set value.

 This one shows the earth leakage current against incoming mains; a bit more sine-like but remember the effect is made worse by the presence of the Tek & the AlicePak.

This is a circuit which has no load and so consequently we're seeing the auto-ranged current draw which is just the quantised noise of the ADC.

nice!

Real live pictures via Antrica - over the Internet

Although it's a shaky iPhone video this is the Antrica system streaming over the public Internet between Root6 West (where the Dev team live) and the main Root6 offices in Wardour Mews. So - it's going via different bandwidth providers (so not just to Sohonet's local pop or anything); presumably all the way to the London Internet Exchange in Docklands. I limited the stream to 4 Mbit/sec and it went all afternoon without so much as a dropped frame. Compression artifacts are rare and minor.

Here is a screen grab from VLC (which can also be used as a viewer).

Another essential gadget for the engineer's rucksack

Hugh and I did a video podcast about essential tools and testers a jobbing broadcast engineer might have in his ruck. An item I didn't mention was a network router - yes, you're right; I came across one of these around a year ago;

It's a very basic NAT (network address translation) router with WiFi. It has a single LAN port and a WAN/LAN port (depending on what mode it's in) and you can pick them up on eBay for less than £20. The best feature is it doesn't need a power adaptor; it plugs into a 13A socket and is little bigger than a MK plug. There are three typical jobs mine gets used for.

1. I'm demo'ing a piece of equipment that has a network connection but I don't have the means to connect my laptop to it because it's at the back of the room (connected to the projector, for example) - I just connect the equipment to the LAN port and then I can hit it over the WiFi from my laptop. This is typically how I demo Tektronix WVR / WFM series TV test equipment.
2. I need internet access but I don't want to hook up to an existing network - either someone drops into the workshop asking me to fix their PC or laptop and I'd rather not give them access to our network; this is a NAT router and so connecting the WAN port to our network and their machine to the LAN port gives superb isolation via the devices firewall. If I'm at a customer's premises and I have the same worry I can connect my laptop to their network with confidence.
3. I need a means of genarating DHCP IP addresses when demo'ing Amulet (i.e. several pieces of equipment).
4. We're on site and all the wiremen want wireless for their 'phones/iPads etc - this is just the way to build a quick adhoc little network.

Friends don't let friends use stock firmware in their routers, part 2

Just a month since I wrote the first piece on this and there are more domestic router breaches.

1. "The Moon" worm on Linksys routers - The worm works by injecting vulnerable devices with a URL-encoded shell script that carries out the same seek-and-hijack behavior. The exploit may also change some routers' domain name system server to 8.8.8.8 or 8.8.4.4, which are IP addresses used by Google's DNS service. Compromised routers remain infected until they are rebooted. Once the devices are restarted, they appear to return to their normal state. People who are wondering if their device is infected should check for heavy outbound scanning on port 80 and 8080, and inbound connection attempts to miscellaneous ports below 1024. It seems that most E-series Linsys routers are vulnerable. 
2. ASUS routers expose shared USB drives over the public internet - The exploits against Asus routers has been known about by Asus for a year and they have yet to correct it in old and current models. 

 Ars Technica's stories are here and here. 

Do I really need to remind you NOT to use manufacturer firmware in your router when DD-WRT, Tomato and others are available?

Antrica - performance at different data rates

After my testing with the Antrica 32000AS I thought I'd better do some screen caps at different data rates; all the tests I did yesterday were at 2048kBits/sec.

32kBits/sec

256kBits/sec

512kBits/sec

1Mbits/sec

10Mbits/sec

It does seem that you don't get much benefit once you pass 2Mbits/sec - now these are only still frames and sub-500kBits you get quite a few dropped frames (I haven't figured out how to increase the buffer size at the receiver which apparently smooths this out at the expense of latency).

Finally, in an effort to get a feel for the overall degradation of HF content I grabbed a couple of frames at field-rate at each end of the encoder's range;

32kBits/sec

10MBits/sec

Antrica video-over-IP encoder/decoders

Every TV industry magazine is currently honor-bound to run a "video-over-IP will replace baseband this year" article at least once every three months. Despite the attraction of sending video over networks there are fundamental problems related not to the fact that it's a network (but, then again TCP/IP was never meant for synchronous, timely delivery of data) but rather the compression used. Actually, not the compression (after all MPEG4 v.10 variants; H.264, AVC etc are pretty good) but the latency; for long-GOP material 12-frames encode is not unusual.

I was pleased to get my hands on a couple of Antrica 32000-series encoder/decoder units. These are HD/SDi and HDMI i/o and you can configure each to be either an encoder or decoder. They are clearly based on a security camera chipset (all the Pan-Tilt-Zoom controls are grey'ed out!) but they have some very nice features;

• The outputs remain live when one is being used as an encoder so you can get a feel for what the untransmitted pictures look like (it isn't just a loop-through of the input HD/SDi). 
• They have up and down converters and so a 1080i input signal can be sent at 720P and an incoming 720P stream can be displayed at 1080i (or SD, for example).
• They have three streaming modes; their own single-port over TCP mode that streams macro-blocks and hence gives incredibly short latency; 80mS at best but more likely 200mS. A buffer at the receiver end can be wound-out to smooth the spikiness of the data rate (with the worsening of the latency). If that isn't working the units fall back to RTSP over TCP or UDP and finally if all else fails MPEG Transport Stream over TCP.
• They also do a software video-wall that will receive a dozen streams.

So, proof of the pudding and all that. I made a 1080i sequence of static frames with resolution gratings and so moving stuff. At only 2MBits/sec (which is allowed to spike-up to 3MBits/sec) I was impressed. Here is BBC HD Test-Card F straight into the monitor and then via the system;

 

The aliasing you can see on the lower gratings is from my iPhone's camera - you really can resolve them to the 15Mhz grating, so no resolution is seemingly being lost.

 These two are taken from the Belle Nuit Montage test chart which shows up all sorts of problems with resolution, colour-space and levels. The finest grating is not resolvable in 4:2:2 encoded material and so what you're seeing here is in part an artifact of the sampling structure of 1.5GBit video.

This is a screen-grab from my trusty Tektronix WFM7100 - I've parked the line-selector on that final grating and zoomed in so that we're looking at 300nS/div on the horizontal. The waveform has been faithfully reproduced with only a low-frequency (I estimate 2Mhz) harmonic. I initially thought this was a fault in the optical transfer function of the monitor but it's there on the signal.

I was playing off my laptop via a Black Magic UltraStudio Express. If you want to play with the clip I've stuck it in my useful clips folder on Google Drive (there is also so DolbyE material in there). It's also worth mentioning they have a software tool for monitoring their end-points. It's called True Manager can as well as allowing you to tweak settings etc you can also monitor in realtime the bandwidth used. This is all very encouraging as tomorrow I will stick an encoder in Root6's office and see what sort of performance I get across the public Internet. As ever with these systems they are adaptive and for still frames they settle at a very low data rate, but at scene changes the system seems to spike to around 50% bandwidth than I'd configured. BUT, the fact remains, I *seem* to be seeing very nice looking 1080i pictures over a few MBits/sec!

System Design with Excel - The Engineer's Bench Podcast

Phil and Hugh go over a few tips and tricks for using MS Excel in the design of film & TV facilities. Find it on iTunes, vanilla RSS, YouTube or the show notes website.

A lie can travel half way around the world while the truth is putting on its shoes.

Not that Mark Twain knew much about fibre optic cable. If he did he'd realise that he was only talking about seventy milliseconds...!

I often have to provide proposals and quotations in response to customer's tender documents and in the last six months I have seen three such tenders specifying tight-buffered fibre for their internal networks.  When I push their staff engineers for a justification they "um and err" and are easily persuaded to do the right thing (i.e. use spliced loose-tube fibre). If you need to read up then I've written a few things in the past.

Last week I came across the following from the Argosy website;

Tight buffered cables are intended for indoor applications. They are more hardwareing than loose-tube cable, as such they are well suited for long indoor LAN connections, burial or complete even submersion in water. Tight buffered cables have a special two-layer coating. The first layer is plastic, the other a waterproof acrylate.

I wonder if this mis-information is their doing?

Friends don't let friends use stock firmware in their routers

Over the years the number of security flaws that come as standard with £50 plastic-box routers have been numerous. That 'free' router that came from your ISP probably suffers from one of these;

1. UP & P enabled by default
2. PING on the WAN side enabled
3. Port 32764 left open

That last one is very serious as it allows a remote attacker to make a query of the router and dump out lots of diagnostic and configuration information. That may be of no consequence but it does allow a hacker to gain knowledge concerning your network and work on other attacks. The problem bedevils Linksys and Cisco models and SlashDot have a good write-up.

In a very real sense your router is the gateway between your network and the wild-west that is the public internet. If you can't even trust the little hardware device that sits in the cupboard under the stairs what can you do? Well, use an open source firmware in your router - Tomato is very user friendly and DD-WRT is very powerful. There are numerous others and since the source code is open it is regularly examined by the community that develops it and so many eyes spot any nasties (malicious or just bad programming) in the code.

I grabbed a couple of Buffalo models from eBay for when my eldest two went away to University and I wouldn't dream of letting my home network be based around a closed-source router.

Chassis vs Signal earth on RS422 remotes

Grounding is essential to reliable operation of any RS422 connections. It is also the most overlooked and least understood. The easiest way to ground your RS422 equipment is to simply use "Earth" ground as your return path. Although easy this may not be the best method for grounding your application, because current leaking from equipment, electro-static discharge (ESD), and lightning all drive current through this path which results in high noise content. The reason for this increased noise level is due to the fact that "Earth" ground presents a relatively high resistance. RS422 is designed to operate normally with a ground potential difference of +/- 12 Volts. During normal operations this is typically not a problem, however during fault conditions or lightning strikes even within ½ mile the ground potential difference can reach hundreds and in some cases thousands of volts. This will most likely result in damage or failure of one or more devices on the RS422 router.

In TV facilities I most often come across three methods of earthing;

1. No earth - assume that the mains return is good (all equipment is class-1 and bolted into it's bay and that signal and chassis earths will be close)
2. Use pins 1 and/or 9 on the 9-pin D-type to couple the chassis earths together; please, don't get me started about intentionally connecting mains earths between different areas! Do you like dealing with induced hum between different areas or buildings?!
3. The best way; using pins 4 & 6 - the signal screens (it's what they're there for).

The job I'm finishing at the moment had a problem with Digital Rapids workstation which wouldn't run through the RS422 router although patching around the router worked - the PC could control a VTR. My first port of call was to test the cabling/router patch by sticking an old Sony RM450 edit controller at the back of the Rapids and pretend the RM450 was the workstation - all good; VTR control and timecode return worked fine (so Tx and Rx doing their things). 

So my first thought was to measure the impedance between the signal ground on the router and the mains earth - high Z so no return patch for the RS422 via the router if it was relying on the mains earth (scenarios 1 & 2 above) and since the router is optically isolated on it's data inputs I wasn't surprised. That is the way it should be done.

Now then; most PCs that are running video apps and have to control a piece of broadcast kit use an RS232 port with an external RS232-422 adaptor. These essentially just balance the Tx and Rx pins and there are several models. None of them (in my experience) actually use a pair of rep coils to properly balance rather they use a pair of op amps in a differential input configuration. This is fine but doesn't have the noise immunity that you get with coils (common mode rejection). What it does mean is that all of the noise immunity of the circuit comes from the electrostatic shielding of the earth and so you better get it right!

I cracked open the cheap'n'cheerful '232-422 adaptors supplied with the rapids and they had the screen connected to the shield of the 9-pin on the RS422 side (so relying on scenario 1 above). Moving that to pins 4 & 6 (scenario 3) fixed the problem. 

As an aside the Adenda "Rosetta Stone" adaptors that Avid supply do the right thing!

DD-WRT and open source router firmware - New Engineer's Bench podcast

Phil & Tim Taylor go over some of the features of the DD-WRT router firmware and how they can be used to secure a home network.


Find it on iTunes, vanilla RSS, YouTube or the show notes website.

Remote access; what's the IP address?!

If, like me, you're tech support for family and friends you often have a need to take remote control of a relative's machine over the internet. There are lots of ways; the easiest being the paid-for services like GoToMyPC, TeamViewer etc which all offer NAT traversal with very  little effort required at each end to make them work. You just give the person you're helping a ticket number and a URL and before you know it (and normally by Java or some other active web content) you're controlling their screen. They have VOIP as well and it's very slick. However, I don't do enough remote support to justify keeping an account going at ten dollars a month and I quite like VNC/RDP etc.

The problem with those protocols is that you need to know the public IP address of the recipient's router and this changes by the vagaries of their ISP and DHCP etc.

So, here's my method for always knowing the public facing IP address of your Mum's computer without having to run anything clever at her end or anything as elaborate as a VPN.

1. Make sure you've made a port-forwarding rule on their router so that when you hit them on port 5900 (for VNC) or port 3389 for Windows remote desktop it gets forwarded through to the target machine; you'll probably have to have given that computer either a fixed IP address or have set the router to always assign it the same DHCP'ed IP address.
2. Have that machine genarate a file at boot-time that contains the correct external IP address along with any other salient data that you might find useful.

The first part requires you to know their router - it's not hard, you'll just need to look around in its web interface. Here's how I do the second part;

I stick these four files in a convenient directory - typically c:\tools\ but anywhere will do. 

wget.exe is an open-source Windows implementation of the common Linux/OS-X tool that fetches text fields from a web server.

GetIP.bat is a Windows batch file that sticks the output of wget into a text file and appends some extra stuff (IPConfig, date and time) and then initiates an FTP session with any web space you may have under your control. Finally index.html is the generated text file (makes the final URL easy to remember).

GetIP.bat

wget http://ipecho.net/plain -O - -q > index.html

ipconfig >> index.html
time /t >> index.html
date /t >> index.html

ftp -s:ftp.txt ftp.plus.net

exit

ftp.txt

ftp-username
ftp-password

cd htdocs
cd bob

send index.html

bye

Stick a shortcut to GetIP.bat in the startup folder (and for extra finesse have it run minimised so nobody sees it) and every time the machine boots you get uploaded to the webserver a very useful status page;

So long as you have a VNC or RDP server running at the remote end you're now only a moment away from being a tech support super-hero!

When SI projects go right; some notes

I've just finished building the technical infrastructure for a big media company who are moving premises. The job has gone rather well and I've been trying to crystallize my thoughts as to how it's differed from jobs that haven't been so enjoyable. From my point of view it all breaks down into three areas - the client, the contractors and time.

The client

• Big broadcast and film companies always have in house people who manage projects and the disturbing trend of recent years is to have project managers who are very conversant with Prince2 or some other methodology, but often don't have a background in broadcast engineering (or indeed any technical discipline).  They tend to be disinterested in the way that non-technical people are when they don't understand something; it's easier to be dismissive than show your ignorance.
• "Getting a good deal" - When I'm quoting for a job and the customer starts talking about discounts and good deals from the outset it raises a red flag for me; they're cheap and will want to reap where they do not sow. They'll be a problem and so I'm going to put fat on the bones of the job where you won't know about it as I'll need that later on. As soon as you start driving us down on cost then assume you aren't getting a good deal. 
• Penalty clauses and "open book" jobs - see the previous point.
• Holding back tens of thousands of pounds because of a tiny fault in one piece of equipment that requires as firmware update from the manufacturer. They won't fix it any quicker because the SI is hurting!

Contractors

• Often on large jobs the builder is the primary contractor and everyone else answers to him. If the SI is a direct-appointment then it's often a nightmare getting access to the things you need ahead of the electricians, data guys, air con guys etc as you are viewed with some suspicion.
• Having the electrican/data guys/gardener run the cat6 cable - it happens and it's never pretty! You don't realise what you do until you work with someone who doesn't do it. A job last year had us trying to unpick 700 cat6 feeds that had just been dumped into a hole in the floor of the machine room. Many weren't numbered and some even had different numbers at each end. It took three of my wiremen ten days to sort them out and identify them. Of course the customer was unhappy to pay for that.
• It's nice to be in the happy position of having enough wiremen to have them play to their strengths. The job I've just come off had between eight and sixteen wiremen and so I could have the guys who were good at fibre just doing that, the good data guy just doing cat6 panels and the good mechanical guys assembling bays and wallboxes. I was even in the nice position of being able to have one guy responsible for stores. It's a rare but pleasant state of affairs.

Time

• The job I've just come off had a very compressed timescale - ten weeks for two machine rooms (seventy+ cabinets) and twenty+ production rooms.  This sort of thing is only do'able if the customer isn't being "cost conscious"
• A timeline is always good; those last minute jobs like programming the router, labeling the patch panels and all the testing take longer than you remember!
• AT LEAST a week is needed to really understand the workflow and hence produce the bones of a design that will work.

In the end you have to guide the customer to understand the golden triangle of all technical projects;

1. Cheap
2. Good
3. Quick

You can only ever have two of these!

The Oscilliscope Watch - an update

I'm looking forward to getting the beta hardware of the Oscilloscope Watch which I've funded on Kickstarter. Here is a recent project update from the developer.

Project Update #9: Beta PCB assemblies on order

Posted by Gabriel Anzzian

Hello Backers!

Sorry for the delay, I've been pretty busy these last few weeks. Here is my monthly report.

SCHEMATICS

I have done some minor changes to the schematics:

• Reduced noise by connecting the 5V step-up switching regulator to the battery, instead of the VDD rail. It will also be a little more efficient, since the regulator is converting 5V from 3.7V, instead of 3V.
• Minor tweaks to reduce current consumption: increased value of some resistors, changed the diodes to low leakage versions.
• Removed the 15pF input capacitors, which aren't really needed for the bandwidth that the OW works with. I also needed the space to add mounting holes.
• Added load capacitors to the 32.768kHz crystal.

PCB

I had a hard time making space to add the mounting holes while still keeping current packages of the components. I only changed the LEDs from 0805 to 0603. Now there are two nice mounting holes on opposite corners, which will be great for fixing the PCB to the enclosure. I also moved the slide switches towards the center to solve a problem with the enclosure as discussed on update #4.

 Oscilloscope Watch PCB rev 1.4 

PCB Assemblies

I originally thought of assembling the Beta units myself, this was when I thought I would have only 10 Beta testers. Now with 28 Beta tester units, and a few spares, it makes more sense to have these assembled at the factory. I am ordering the assemblies and they should be ready in about 6 weeks.

BATTERY

I am going with a 380mAh battery, it measures 40mm x 30mm x 4mm, the dimensions of the watch are not changing. I have already received enough samples of these for the Beta tester units. The battery life should not change much from the initial estimates.

BACKLIGHT & FRONTLIGHT

I bought a translucent filament to use on my 3D printer to make a backlight diffuser, it didn't work. The problem is not because of the translucent diffuser, which I already knew that it was not going to be too good. The problem is the LCD it self, it does not let much light go thru.

 Backlight experiment 

So I started to research what I needed. I contacted Sharp and they referred me to a company that does "front lights". I have just began talks with them, we are signing NDAs.

The Beta units will still have the backlight diffuser, but this is to make everything fit together, rather than functionality.

Not many changes to the enclosure. I tweaked the sliders to fix the collision problem, I moved the charging LED location to right above the USB connector, and made the LED see-thru holes circular. I also added the screw bosses on the TOP part.

 

SOURCE CODE

I haven't done much to the code, only some minor tweaks to reduce current consumption during the watch mode. Once I get the Beta units, I will set up a repository, initially for Beta Testers. I am looking forward to working with the Beta Testers!

A lot of work to still to be done, but it sure is fun!

Photons vs. Electrons

At ten gigabits ethernet over copper cable really struggles. Everything has to be just right and even well terminated twisted pair cable is on the hairy-edge.

On the job that I've just finished had a lot of fibre and copper data and the time to test (on a per circuit basis) is much higher for copper than fibre. With OM3 fibres so long as you have an acceptable sub-3dBs of attenuation at 850nM ten gigs is a doddle. We had to re-terminate maybe half a dozen circuits and using our INNO core-alignment splicer it takes no time. On the other hand getting the copper data cables right is a mission with Near-end cross-talk, alien cross-talk and return loss all having the be measured across four pairs. The output (above) is from our Fluke DTX-1800 analyser.

As an aside, one of the freelancers I use a lot showed me a brilliant trick with fibre panels); the BT standard for core-order involves having the coloured and striped cores 12 couplers away from each other in a 24-port panel. The better way is to put the coloured and striped cores next to each other in the same duplex pair so that if you make a mistake it's easily rectified at test-time.

A week is a long time in Blackmagic firmware!

I recently installed a 288x288 Universal VideoHub from Blackmagic - bear in mind this thing has 576 coaxial video connection and 288 RS422 ports it takes more than a day for a wireman to do a nice job of plugging it up.

here's one we did earlier!

Also bear in mind this is a modular system with space for 72 interface cards - each one has four HD/SDi ins and outs (up to 3G 1080 50/60P fact fans!) as well as a proprietary connector with four RS422 standard machine remotes.

So - once unboxed I filled up the chassis with cards, control modules and power supply cards and bolted it into the cabinet. However - the power supply units were delayed and so I got Tony the wireman to finish dressing it in before I powered it up; what a mistake!

I eventually got around to firing it up expecting to start programming it the same day but imagine my horror when I discovered 20 of the 72 modules were not showing up in the GUI. Swapping cards around showed that I did indeed seems to have twenty duff interface cards; pretty poor quality control I thought. BM UK's tech support department gave me the impression they didn't believe me and after lots more swapping of cards they agreed to take them back. 

I called them the following day only for them to tell me they couldn't find any faults with the cards we'd returned! I asked them to go over their testing methodology and the engineer started with "...I upgraded the firmware on the cards and inserted them into our test chassis"; exactly how I'd started - well, long story short, in the three days between me starting and them getting the cards to test BM had issued a new version of firmware. They'd gone from 5.0.4 to 5.0.5 without giving any indication to UK support as to what the changes were. It turns out that 5.0.4 disables some revisions of the card! How many of that version of the cards did I have? Twenty.

It seems like 5.0.4 was only out for less than two weeks...?!

The Engineer's Bench - hosting a video podcast

So for whatever reason Blip.tv have shut down the account that Hugh and I were using to host the RSS feed and media for the video podcast we do. Without any warning they shut off making any changes to the account (like re-directing the RSS feed and I hadn't been sensible enough to run it via FeebBurner) or even putting up a "so long and thanks for all the fish" clip up to let our iTunes & other podcast watchers know that the feed was dieing. Apparently we're a bit dry; they don't want engineering/educational screencasts, rather stuff that's more 'off the wall'. Ho hum - it was free (and free is never good) and so we've stretched to paying for hosting. 

From now on all Engineer's Bench goodness will be at it's own domain;

http://www.engineersbench.co.uk

What is worth noting is that only a minority of our watchers do so via iTunes/RSS - most folks now get it via Youtube, and so that has been unaffected and can still be found at the same old place.

We've been a bit slow recently but it's just the pressure of work. We have several planned:

• KVM-over-IP - a technology whose time has come 
• Software tricks and tips with Excel and other software for broadcast engineers 
• Hardware pt.2 Raspberry Pi and NetIOM control boards

So hopefully 2014 will produce a return to form for your favorite broadcast engineering related video podcast!

Oscilloscope watch

The watch for the electronic geek. All the features of a watch combined with an oscilloscope and a waveform generator. I've signed up to fund the Kickstarter project which has reached it's goal - happy days!

Features:

• Mixed Signal Oscilloscope: Simultaneous sampling of analog and digital signals.
• Advanced Trigger: Normal / Single / Auto, with rising or falling edge and adjustable trigger level.
• Meter Mode: Average, Peak to peak and Frequency readout.
• XY Mode (Plot Lissajous patterns or see the phase difference between two waveforms).
• Spectrum Analyzer with different windowing options and selectable vertical log.
• Horizontal and Vertical Cursors with automatic waveform measurements.
• Arbitrary Waveform Generator with Sweep on all parameters.
• Display options: Persistence, Different grid options, and more.
• Curve tracer function

I'm signed up as an International Beta Tester. The Beta Testers will receive a prototype as early as December, and a production unit with all accessories in May. Beta Testers will be expected to be involved with the design and report bugs along the way. Apparently this prototype will initially not work, but will start to work as firmware is developed. The prototype hardware may need changes so you might need to do some soldering. The case will be 3D printed with the current prototype design. Come May 2014 the production units will be available and so I intend to do some video blogging as soon as I receive the prototype and keep with it all the way through to the final version.

Too busy to blog!

I'm snowed under; long days helping a big facility to move premises. I've tried to take half term off too spend time with Sarah and James (the only boy left at home since his brothers went to Uni last month) but have wound up working two days so far this week - ho hum.

So; here are just a few technical things I had to get off my chest.

• If you use a Blackmagic Ultrastudio Express (I do - it's a a great way of playing out HD/SDi for demo'ing equipment, calibrating monitors and displaying training material) then be aware that the current version of the app/driver (v. 9.8 currently) is very unstable on OS-X 10.9 Mavericks - use the previous version 9.7.8 instead - all here.
• Do you ever need to demo/test DolbyE encoded material - this is the clip I use (from my pals at National Geographic)
• Do you ever need to do audio shuffling within an HD/SDi signal - shuffle, adjust levels, correct phase reversals, delay (up to 2,400mS), maybe apply dynamics? The most effective way I've ever found of doing this is with an AJA HD10AM, a Yamaha 0196V and the MY8AE option card; £2.5k for full control of two audio groups within an SDi stream; You couldn't do that with anything from Bel, Snell & Wilcox, TC Electronic or any other manufacturer of audio processors.
• Hard drives - "MTBF= 30k hrs"; inter-quartile range is where >50% of HD fails occur. A few last 100k hrs, some only 2hrs as I discovered when the replacement cloned hard drive in my media computer failed after a couple of hours of use. Thankfully I'd cloned it twice! Don't trust spinning hard drives. A motto for our age should be "Friends don't let friends use RAID5"!

That's it, Christmas can't come soon enough!

Windows remote desktop for Raspberry Pi

It's not very open-source/Linux but the best remote desktop I've found so far for the Pi is the venerable Windows RDP (Citrix Winframe or whatever else you want to call it). I know you should be able to run an X-server and all would be well but I haven't been able to find a nice combo that works across all my Windows, Mac and Linux boxes; RDP is the only lingua franca.

So - to set it up on the Pi;

1. Start up your Pi to the terminal prompt. 
2. Type the following command "sudo apt-get install xrdp"
3. If promoted enter your password (the default is "raspberry")
4. Type "Y" and press enter.
5. This is now installing xrdp onto your Pi which is the software we are going to use for the remote desktop connection.  Wait for it to complete.
6. Restart your Pi.  We are going to check that xrdp is going to start up automatically.
7. When your Pi has booted to the command prompt look for [ ok ] Starting Remote Desktop Protocol server : xrdp sesman.  This shows you that xrdp is installed and automatically starting up on start up of your Pi

It takes best part of half an hour to extract and install but once running it's the most responsive experience - far better than VNC and even better than Apple remote desktop. Not quite as good as sitting at the machine (or over an Amulet/Teradici network connection) but excellent none the less. 

If you want to get to it via your router or firewall open one port - TCP; 3389.
Client for OS-X, Client for most Linux versions.

An alternative guide from May 2016;
http://www.circuitbasics.com/access-raspberry-pi-desktop-remote-connection/