Slashdot Mirror

In the previous stories about the new X acceleration layer there was talk about removing the idea of accelerating drawing of lines with hardware from the acceleration framework.

For me, that is very, very bad as what I do needs to draw about 30-50 thousand line segments a second, and not having line draw acceleration would suck.

Now, along comes OpenVL - which sounds like it would be perfect for accelerating oscilloscope-type operations.

I can only hope that real hardware to do this becomes commonplace.

Now this is something a veteran embedded software engineer can really get excited about!

Most wireless systems are becoming little more than a means of shoving TCP/IP packets over the air, with voice crammed in the cracks. As a result, you need hard realtime processing, but you also need UI, protocol stack, and layer 7 (applications). And while a big box can get away with multiple processors, a phone cannot.

Having a hardware partitioned, hard realtime PLUS Linux system WITH full virtual memory (not uCLinux without virtual memory) is VERY compelling for an embedded developer.

Of course, this trend has been going on for some time - Xilinx with their 2 or 4 PowerPC-core Vertex 2Pro FPGAs, the various Strongarm/DSP, PowerPC/DSP and MIPS/DSP hybrid chips from Motorola et. al., plus things like the K.U. Realtime extensions and Monte Vista kernels.

I definitely will be keeping an eye on this at work....

It has been my experience that the public is confused by words - anything more complicated than "push here" is going to be trouble.

I design fairly complicated equipement to be used by (supposedly) trained radio technicians. I recently sent out a replacement file to a specific customer to see if we had a problem he had reported fixed.

Mind you, this customer was working to integrate our equipment into an automated test station - one would expect this person to have at least a cluon or two.

In the instructions for the replacement file, I stated most clearly:
Step 1: update the unit to the latest firmware.
Step 2: after you have done the update, apply the attached replacement file.

Pretty simple, huh? Guess what: the customer did NOT do the update first, and wedged the equipment.

Now, had this been a true production update, I would have added check code to verify that the patch would not apply unless the firmware version matched, then I would have spent the hours validating that the check code actually would catch version mismatches, then released the patch. During all those hours I would NOT have been getting the other features ready.

But this was one customer, and one that should have been more technically adept than most. So I felt that spending thirty seconds explaining the process would be a better use of my time than spending the hours to make it idiot-proof - after all, I was not dealing with an idiot, was I?

The general public runs at just over the level of a caveman (no offense intended OOG if you are still listening...) - anything more complicated than "push here" will elude them (and given that I have seen footage of bank robbers foiled by a "PULL" rather than "PUSH" door, I have my doubts about that) It would seem the average person's reaction to any printed matter is "WORDS! WHY DID IT HAVE TO BE WORDS! OHH, MY HEAD'S ABOUT TO EXPLODE!"

Granted, much of the terminology used in selling computers to the lay public is too complicated for them to understand, but trust me - trying to dumb it down won't work, unless you can determine how to describe a computer in grunts and pointing.

I am well aware of GnuRadio - in fact, if you look at the FAQ, you will see I am quoted in it.

Also, I do Software Defined Radio for a living.

However, the point of my previous message is that the average person with the average receiver is not going to be able to receive this signal.

I HATE GPIB. I loath it. I am forced to support GPIB when my project has a perfectly good Ethernet port.

National Instruments has a "driver" for their cards under Linux, but their "driver" does not do things in the One True Unix Way - the driver is more of a shared library you link against your program that provided a slew of functions to manipulate the card. What it does NOT provide is a /dev/gpib interface that you can select(), poll(), and such on.

I would ask this: if your goal is control, why not use TCL/Tk for the control? That way you get an environment that your end user (the scientists) can play around in without edit/compile/link/curse cycles. You also get a degree of portability.

Yes, the problem is that most hardware venders do not provide a lower-level programming model - a) because they are afraid of the competition cloning their board and b) because most folks developing software with them want a LabView|LabWindows|HPVEE|DCOM interface.

However, there is a small ray of hope: the government JTRS (Joint Tactical Radio System) (the new software defined radio standard The Men In Green are wanting) uses CORBA to do all the module communication. Now, if we could just pursuade industry to follow that trend! I'd love to provide a CORBA interface for my network enabled device, rather than the current solutions!

OUCH!

I think the problem is the immediacy of a web site - it is possible to make quick changes and see the results (as opposed to a lengthy edit/compile/link/load/swear cycle) so people get used to making quick changes. When you can make a quick edit and immediately see the results, you get sloppy - when you are looking at a 15 minute e/c/l/s cycle you are a bit more careful.

On my project at work we do much of the work in TCL/Tk - and so you can make changes while the system is running. This is good, in that when you are doing communications protocol testing you often need to experiment to determine the things the standards didn't define, but you can all too often get into the habit of "Well this looks simple enough - I'll just throw it in to HEAD rather than fully checking it - what could go wrong?" (and I am no better nor no worse than the rest of the guys under me about this, though I do try to set an example).

That is why I feel it is so important to make this point over and over again: No matter how tempting, test before going live.

It's also illegal to sell or manufacture a device capable of intercepting cell phone conversations.

Reading the lengths to which you must go to get a remote display on your Windows machine amazes me.

Give me the same basic hardware, but rip WinCE out and put a lightweight X server into it, and I could remote the display on my workstation without any software changes on it at all (except perhaps for adding a line to my X0.hosts file).

AND if the table spoke SSH, I wouldn't even have to do that.

AND the fact that I could also redirect the displays of my SGI, my other server, my service monitor, and anything else that spoke X Windows system protocol.

For all you naysayers who poop-poo the need for network transparency in your GUI, I say:

BEHOLD

Before we start griping about a Flash player for PPC Linux, how about we gripe about a Flash player that works decently under ANY Linux?

Specifically, I have noticed that Flash under Linux runs like Unreal on a 286, even on my Dual-P3 1GHz with a AIW7500. CPU load during playback is not close to 100% of one CPU, but I get a slideshow poorly synced with the sound. Of course, on Windows running on one processor of the same machine I get a very smooth playback well synced to the sound (as well as a dirty, slimey feeling that showering just doesn't get rid of).

I'm not running ESD or any other sound daemon, so that's not it.

And don't tell me that "X is slow" - bullshit. I work on an X based test instrument and can shove more graphics down the card than the DSPs can generate. It's just that Slackromediocre have put no effort into making Flash run worth a crap on anything that has a lower case x in the name.

Now, given that they have started this effort to make Flash the "thin-client solution", don't you think they ought to make it work well on a thin client?

On a project I designed, I deliberately designed the system to have TCL built-in, for a very simple reason.

Scripting has its place, as does more conventional compiled code.

Use compiled code to do the heavy lifting - in my case, things like FFTs, signal analysis, and such.

Use scripting to tie it all together.

That way, when you are trying to figure out the problem domain ("Now, what does the radio expect me to do when it sends a GTC message - maybe it wants a CASSN message? Clicky-click - No, doesn't seem to be it. Maybe a IDN message? Yep - that's it.") you can try things out very quickly.

You can also very quickly string together smaller functions into larger blocks ("Ok, to test the radio, first I do this, then that, then the other.")

I cannot even begin to imagine how long simple things would take if we didn't have an embedded scripting language.

Man, I wish the Gnu folks would build their own hardware card rather than the card they are currently using - it's quite expensive.

I'd love to see them put a decent FPGA, an Intersil 50216 4 channel digital downconverter, and a nice 60 Msample/sec 12 bit flash A/D converter on the card - they could do that for a bill of materials of about US$200, and have enough power to do the capture properly.

Before you say "Fine - why don't YOU design it?": I'd love to get more involved in GnuRadio, but I'm afraid of potential conflicts of interest both ways - contaminating GnuRadio with my professional work and possibly exposing my employer to problems with GPL infringment.

Also, is anybody big in the Gnu Radio project going to be at IWCE (International Wireless Convenention and Exposition) March 10 - 14? If so, where? I'm getting in on an exhibitor's badge - maybe I could get pictures?

I love the fact that a good, Free Software voice codec is out there, and here are my reasons:

1) Ham Radio. The Tucson Amateur Packet Radio organization is working on experimental digitized voice over amateur radio applications, and a couple of venders (mostly Kenwood) are offering radios that have this ability. Right now, TAPR are looking at using DVSI's IMBE vocoder, which is QUITE expensive and VERY not-Free. The availability of a Free codec would greatly improve the availabilty of this protocol.
2) Currently, The Association of Public-Safety Officials (APCO) (the folks who define the specs for the radios used by police, fire, and government) have defined the current digital trunked radio standard, APCO Project 25 as using DVSI's IMBE vocoder. While this is licensed under a Reasonable And Non-Discrimitory license, if you want to license the IMBE vocoder for a P-25 project, you will cough up US$100,000.00 for the privilege (I know firsthand, as the company I work for has done this). Uniden, Radio Shack, and other scanner companies are looking into putting this into their scanners, so they have had to cough it up as well. A Free vocoder would allow anybody to build a product with this capability in it - you could even use a scanner and your sound card to decode the Phase 1 C4FM format signals.

Like so many other things, a Free Software tool to do these things would greatly accelerate the industry. I hope Xiph does well.

Actually, I make a very good living as a software engineer, thank you very much.

I have worked both with MS WinNT and with Linux. I have written low-level drivers for both. I have designed systems of great complexity.

I can trivially turn your points around by pointing to Linux, to Mozilla, to Apache, to Sendmail, in fact to all of Sourceforge.

The single biggest thing holding back drivers under XFree is the fact that talented individuals such as myself cannot get the programming documents for boards like the ATI without signing an NDA - and to be given the opportunity to do so requires you to ALREADY be a "registered" XFree developer. Can you say Catch-22?

Now, if somebody like Jumptec, Ampro, or any of the other embedded CPU board makers would use this! I'd love to have that for my embedded system - fast graphics for all the traces, USB 2.0 for RF control, two Ethernet ports for access...

I wonder if anyone could pursade nVidia to put one of these in there... They have everything else....

First, my C.V.:

I've been a professional embedded software designer since 1987. My current project has 4 DSPs and one main processor. I have several projects out on the market (I have several more, but I got tired of pasting Google links). I run the gaumit from DSP algorithms to systems design to UI design to OS work.

OK, on to my point:

There's two ways to look at Embedded Linux. The first is to look at how much money is being made by companies selling Embedded Linux services - comparing Lineo with Wind River. By this standard, Embedded Linux isn't doing very well, because few companies are making a killing selling Embedded Linux tools. The second way is to look at design wins - how many projects are having Linux built into them. This gets tricker: how do you build up a list of design wins? For a commercial product like VxWorks, you just ask Wind River "How many new licensees of VxWorks were there this year?" But you cannot do that with Linux - as has been noted elsewhere most folks going to Embedded Linux just pull down RedHat, Debian or some other distro and run from there.

Now, let me shed some perspective on this. Embedded systems come in all sizes, from your smart themostat to telecom systems. If you are design a small device, with no display (or a very simple display), no network connectivity, and very small amounts of RAM and ROM, you don't want to use Linux - it's overkill. But, if you do the kind of stuff I do, where you have GUIs, gigabytes of disc storage, network stacks, printer support, scripting, and so on, you DON'T want to use something like VxWorks - they didn't have a DHCP client in their earlier version, they didn't have DNS, they don't have very good printer support, forget SMB (save if you wish to pretend to BE a printer), the only GUI they really support is Java on a frame buffer. Also, their hardware support is pretty lame - if you deviate just a little bit from the supported boards they have, you can kiss good support goodbye (their X-Scale ports don't activate the on-chip cache - farewell to half your CPU speed).

But would I go to Lineo for their package? No, not because of any intrisic failing of Lineo, but because I don't NEED to, and by the time I clear the crap with our Contracts person, I'm slipping schedule.

Believe me - I see the FUD in all my trade journals. The problem it they are geared to deal with the likes of Wind River, and they don't know how to measure something that can be downloaded free. Furthurmore, Debian doesn't buy ad space in EE Times, so it's hard for EE Times to get excited about them.

Bzzt! No, this is what I do.

Data packets? You wanting to look at trunking, or mobile term stuff?

I do this for a living, and I can tell you this won't help you listen to cellular.

First, all they are doing is taking the 455kHz IF from an existing radio, digitizing it, and using the computer to do the demodulation. Thus, if your radio won't receive the cellular band, your computer won't either. And if your radio can tune into the cell band, you can listen to AMPS without a computer - it's just narrowband FM.

Now, if you are talking about GSM, PCS, CDMA, or anything other than AMPS, then you will need more than just a receiver that can tune those bands. CDMA is spread over 1.5MHz of spectrum - unless your radio has an IF that wide you are out of luck.

GSM and PCS (which is just GSM at a different frequency) is narrowband, but it's still more complicated than FM- you need to be able to receive the complex (in the a + (srqt(-1))w sense of the word) waveform, and pull the bits out of the air. Then, you need to decode the protocol, run the vocoder algorithm, and generate the audio. We use TI C6X DSPs capable of 1.6BOPS, with special opcodes to help the decoding, and Special chips to do the grunt work and it still takes a lot of work to get it to run in real time.

Now, if you are a ham, and you want to do sideband, PSK31, or other modes, this is a great thing. But don't expect to be able to monitor your neighbor's phone with it.

Besides, if you ever HAD monitored cellular, you't realize it's about as interesting as watching grass grow.

Actually, all modern power supplies ARE isolated from the power line - that's the core of a switching power supply.

First, the incoming AC is rectified to DC and filtered. This gives you 300VDC on about 10 to 1000 microfarads of capacitance - enough to kill you dead if it goes through your chest. That part of the circuit is directly connected to the power line.

Then the DC is chopped by a transistor and fed into a transformer (this is the "switching" part of the power supply). This chopping is done at between 60 kHz and 1 MHz (depending upon the power supply). The other side of the transformer (the secondary) is completely isolated from the power line. This voltage is then rectified, filtered, and supplied to the rest of the device. The voltage is measured, and fed back to the switching controller, which drives the switching transistor through either an optocoupler or pulse transformer, closing the feedback loop and regulating the voltage.

If you look at a modern switcher, you will usually see the "hot" side is completely isolated - even unto having sections of the PCB cut to prevent arc-over.

So, the bulk of the power supply, and the rest of the chassis, are NOT electrically connected to the power line. In fact, less of the system is connected to the power line than in an old style line frequency tranformer design. (Now, there were some old designs that rectified the power line and used that directly. THOSE designs were "hot" chassis designs, and were widowmakers...)

That said, you shouldn't go poking around inside a monitor or TV unless you know what you are doing. The anode voltage on the CRT is between 12kV and 25kV (although the source impedance is high enough that it won't kill you). However, the deflection circuits that sweep the electron beam across the CRT are at about 400V and have enough energy to knock you on your ass.

I've worked on TVs, monitors, radio transmitters (including tube based 250 watt repeaters (3kV at .1 amp, never work alone, one hand in your back pocket)) I design these things for a living.

And I agree with several of the posters - I'd like to see this sort of thing work its way into a box next to the computer.

Take
this bad boy, a four channel programmable down converter - 4 radios on a chip. You feed in 1 to 4 IF data streams, and this guy will decode them - about 2 billion operations per second, on a chip the size of your thumbnail (micro-ball-grid array). I work with its little brother, the 50214, on
my project, and I can't wait until I get past the big stuff and get some time to play.

That's the sick thing about soft radios: you do one down conversion from RF to IF, then digitize it, and from there on it's all math. When you are a ham operator, a math geek, and a software engineer, and you get paid to play with these, well, life is good.