Sunday, May 27, 2018

The RPM200 is coming

Morning all,

Well, I bit the bullet and borrowed a car for this event. Put the Kenwood D710 in the car and currently have my 2 meter band half wave over half wave vertical on a mag base. This antenna is rubbish on 70cm, I imagine the pattern is all over the place, but it gets out just fine on 2 meters. I have had some long haul APRS packets

I like the Forrester more than I expected and can see one in my future. Have spent a little too much time looking at lift kits and A/T tires ;) The Forrester has roof racks and I need to hunt for some of those antenna mounts that bolt up to the Rhino racks.

No idea how I would mount up a HF tuner and antenna to the back of it yet. Perhaps a tube frame rear bar with swing away tire mount like you find on ladder frame four wheel drives? In the mean time, I will install a couple of other radios; a UHF CB and a commercial high band VHF radio licensed especially for the event. Photos soon ...

73, Kim VK5FJ

Tuesday, July 18, 2017

A tale of two projects, some travel and USB serial interfaces

Morning all,

Back in the mood for squirting some text into a blog post after a while away focusing on other things. Amateur radio may be a life style for some, alas as a hobby it doesn't get the time it deserves at the moment =)

Yesterday I resolved a problem that had been plaguing me for months. If you remember some time back there was an issue with FTDI that release a driver that would "brick" non-authentic devices. Well, yes it is those authentic devices that I have been working with. Yes the expensive authentic ones.

I have an embedded SoC device that is based around an wireless access point, that has been encapsulated on a PCB with all the peripherals broken out. There is a D25 port with many of the GPIO pins, power, serial console and other pins for this particular application.

I had some issues with the FTDI USB to serial devices, they connect fine at 115200 baud. They run fine for a while when connected to the embedded machine. After a minute, sometimes as long as five minutes the USB to serial device has some corruption, then ceases to function.

I spent several weeks trying to determine if this is the embedded device failing. How was it failing? Why was it failing? Why was nothing in the logs? Etc, etc, etc.

So I moved focus. What happens when I plug in my VT220? Surprisingly I get the same behavior, what ever the speed, after a while there is corruption, then something fails to pass data across the serial link.

I spent some time looking at the connections, looking at "veroboard" and making sure all the solder joints were good, testing for dry solder joints, then soldering up new serial port cable hardware. The issue persisted. I would get a clear 60 seconds after the first serial stream corruption before the USB serial cable ceased to operate.

This is an important work project, but it was burning time that I didn't have.

I put it all aside and focused on other projects while work became very busy. The other project is radio focused and did not require a USB serial interface, thankfully. Well, I might have picked up this problem sooner if this were not the case. At the end of the busy work period there was some travel, many many hours in a car delivering things around the country, VK5 -> VK2 -> VK3 -> VK5. Adding another 3,000km to the little white car. The following week and another 2,000km of car travel to and from a conference. Weekends absorbed by driving and a bit of thinking about the USB serial problem.

At the conference I describe the problem to a few folks there were working on various embedded systems. A few suggestions were offered, a few experiences shared. However the only common experience was "don't use authentic FTDI cables". This wasn't very helpful as I had a bunch. They all behaved this way.

So, inspired by talks and projects from the conference, I ordered a few Raspberry Pis and some new FTDI USB serial cables. Weeks flew by. Eventually they arrived. I gingerly tested one. No corruption, no lockups. The embedded machine ran on the bench over night with no issues, passing packets across Ethernet ports. Been running for days now. The configuration on the device is now well under way. I am aiming to publish more on that soon.

I packed it all up, took it work work and explained to the guys in the lab the experience. I was offered a pair of scissors to "fix" the authentic FTDI USB serial cable. It was an unfortunate waste of time using these expensive FTDI USB cables. I have put them in a labeled box; "test before use". I have on order more of the cheap Chinese ones, because they work. Why? I do not know. Maybe it is a driver issue? I hope to look into this in the future.

In other news my 2 meter sniffers arrived from Bryan VK3YNG for radio direction finding! Been a long time coming. Guess what I'm up to this weekend?

73, Kim VK5FJ

Thursday, April 4, 2013

Stact traces are fun ...

I turned off a Western digital external USB hard disk and BOOM!

Syslog threw this in every terminal window;

Message from syslogd@greyarea at Apr 5 09:38:37 ...
kernel:[845101.225977] Oops: 0011 [#1] SMP

Message from syslogd@greyarea at Apr 5 09:38:37 ...
kernel:[845101.225979] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/class

Message from syslogd@greyarea at Apr 5 09:38:37 ...
kernel:[845101.226072] Stack:

Message from syslogd@greyarea at Apr 5 09:38:37 ...
kernel:[845101.226085] Call Trace:

Message from syslogd@greyarea at Apr 5 09:38:37 ...
kernel:[845101.226179] Code: 00 00 00 f0 26 4b 81 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 c0 37 4b 81 ff ff ff ff 01 00 00 00 00 00 00 00 d8 0e 2b 01 88 ff ff e0 d8 0e 2b 01 88 ff ff 00 00 00 00 00

Message from syslogd@greyarea at Apr 5 09:38:37 ...
kernel:[845101.226208] CR2: ffff88012b0ed8e0

I wonder what the hell happened there? Lets look at dmesg. Aaah huh...

[845101.160570] usb 2-1.8: USB disconnect, address 28
[845101.225961] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[845101.225964] BUG: unable to handle kernel paging request at ffff88012b0ed8e0
[845101.225966] IP: [] 0xffff88012b0ed8e0
[845101.225973] PGD 1002063 PUD a067 PMD 1dac40063 PTE 800000012b0ed163
[845101.225977] Oops: 0011 [#1] SMP
[845101.225979] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/class
[845101.225982] CPU 6
[845101.225984] Modules linked in: ses enclosure hfsplus isofs udf crc_itu_t nls_utf8 nls_cp437 vfat fat usb_storage ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables sco bridge stp bnep acpi_cpufreq rfcomm parport_pc l2cap crc16 ppdev lp parport cpufreq_stats cpufreq_conservative cpufreq_powersave bluetooth rfkill cpufreq_userspace vboxnetadp vboxnetflt vboxdrv kvm_intel binfmt_misc kvm fuse loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd nvidia(P) soundcore psmouse snd_page_alloc i2c_i801 pcspkr i2c_core wmi evdev processor button serio_raw usbhid hid ext3 jbd mbcache dm_mod sg sd_mod sr_mod crc_t10dif cdrom ahci ehci_hcd libata usbcore nls_base scsi_mod thermal e1000e thermal_sys [last unloaded: scsi_wait_scan]
[845101.226037] Pid: 19273, comm: umount Tainted: P M 2.6.32-5-amd64 #1 5498PY9
[845101.226039] RIP: 0010:[] [] 0xffff88012b0ed8e0
[845101.226043] RSP: 0018:ffff8801daf35bc0 EFLAGS: 00010282
[845101.226046] RAX: ffff88012b0ed8e0 RBX: 0000000000000000 RCX: ffff88021a34f978
[845101.226048] RDX: 0000000000000010 RSI: ffff88021a34f8f0 RDI: ffff88013ce72340
[845101.226051] RBP: ffff88013ce72340 R08: ffff88013ce72340 R09: ffff88022e08b7e0
[845101.226053] R10: 0000000000000002 R11: ffff88012b0ed8e0 R12: ffff88021a34f8f0
[845101.226055] R13: 0000000001000000 R14: 0000000000000001 R15: 0000000000000001
[845101.226058] FS: 00007f39c88cf740(0000) GS:ffff880008b80000(0000) knlGS:0000000000000000
[845101.226061] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[845101.226063] CR2: ffff88012b0ed8e0 CR3: 000000019932c000 CR4: 00000000000026e0
[845101.226065] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[845101.226067] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[845101.226070] Process umount (pid: 19273, threadinfo ffff8801daf34000, task ffff88012b928e20)
[845101.226072] Stack:
[845101.226074] ffffffff811800ff 0000001000000002 0000000000000000 ffff88023c2fc901
[845101.226077] <0> ffffffff81300096 ffff88023c2fc9e0 ffff88022e08b7e0 ffff88013ce72340
[845101.226081] <0> 0000000000000000 0000000000000000 0000000000000000 ffff88022e08b7e0
[845101.226085] Call Trace:
[845101.226090] [] ? get_request+0x1f0/0x2ba
[845101.226094] [] ? do_page_fault+0x2e0/0x2fc
[845101.226097] [] ? get_request_wait+0x21/0x188
[845101.226105] [] ? scsi_execute+0x3b/0x12f [scsi_mod]
[845101.226112] [] ? scsi_execute_req+0x40/0xb9 [scsi_mod]
[845101.226119] [] ? scsi_execute_req+0x87/0xb9 [scsi_mod]
[845101.226126] [] ? ioctl_internal_command+0x64/0x16a [scsi_mod]
[845101.226131] [] ? pagevec_lookup+0x17/0x1e
[845101.226139] [] ? scsi_set_medium_removal+0x5a/0x98 [scsi_mod]
[845101.226144] [] ? cdrom_release+0x18f/0x1fe [cdrom]
[845101.226150] [] ? smp_call_function_many+0x1ce/0x1ec
[845101.226154] [] ? invalidate_bh_lru+0x0/0x42
[845101.226159] [] ? sr_block_release+0x11/0x1d [sr_mod]
[845101.226162] [] ? __blkdev_put+0x94/0x14c
[845101.226166] [] ? deactivate_super+0x60/0x77
[845101.226170] [] ? sys_umount+0x2dc/0x30b
[845101.226173] [] ? do_page_fault+0x2e0/0x2fc
[845101.226177] [] ? system_call_fastpath+0x16/0x1b
[845101.226179] Code: 00 00 00 f0 26 4b 81 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 c0 37 4b 81 ff ff ff ff 01 00 00 00 00 00 00 00 d8 0e 2b 01 88 ff ff e0 d8 0e 2b 01 88 ff ff 00 00 00 00 00
[845101.226201] RIP [] 0xffff88012b0ed8e0
[845101.226206] RSP
[845101.226208] CR2: ffff88012b0ed8e0
[845101.226210] ---[ end trace e40465e307868faf ]---

I might just reboot now to be on the safe side.

Monday, March 25, 2013

HFPack update

Right, this has been sitting in the drafts folder too long. So here it is;

I picked up an ALICE frame a couple of years ago with a large field pack. I got it specifically to build up a HFPack to run 40/20/17/15 meters. Its been a long time coming, but I've made a bit of progress in the last month.

Over the last year I picked up a few MOLLE style pouches. I got these because the are the right size and shape to hold the pair of 7 Amp Hour SLA batteries and the FT857. I wasn't happy with strapping the MOLLE pouches on to the ALICE frame directly. They didn't sit right and moved around too much.

I had done a little homework before I got to this point. I had read up as much as I could on ALICE equipment and lots on MOLLE equipment. There are quite a few backpacks that have the rear face of the pack with the MOLLE attachment area. I wanted to replicate that on my ALICE frame to make it easy to attach the MOLLE pouches. Eventually I found a photo of a sleeve that had the MOLLE attachment area on it. It lead me to a site that had them for sale for less than 100USD. However they did not ship them outside the USA.

So I purchased 10 meters of 1 inch webbing/strap. We had a three day long weekend of 35c, 36c, 38c. I sat in the HAM shack and proceeded to stitch up an adapter. The example I found had a solid canvas backing with the strapping on the back. I couldn't find anything suitable so decided to just use more 1 inch wide strap instead. After 10 hours of stitching, sweating, unpicking, stitching, sweating, swearing and lots of coffee I got to this point, with the loop around the frame and horizontal straps;

Note this isn't the finished webbing, but this is how it attaches to the ALICE frame;

Laying up the pouches everything looked good and I added the vertical straps. At least another 10 hours it looks like this;

I have use two of each of two style of pouches;
- Firstly the pouch that carries the FT857; T.A.S. 3374 Large Pouch
- Secondly pouch that carries the 7AHr gelcell; T.A.S. 036F Full sized Universal Pouch

A shot from the left side of the pack, note the fibreglass poles that need to be adapted for an antenna;

There is more to come. Probably lots more. I've only started tinkering with the power supply harness and coax feed.

73, Kim VK5FJ

Tuesday, December 4, 2012

Blast from the past... VAXEN!

The Linux on VAX mail list errupted into activity this last week! I've been tinkering with old VAXes since 2001 and have a cache in the shed. Might be time to drag some out over the holiday break, get things running and submit some patches =)

Oh, found a nice resource;

Sunday, November 11, 2012

News - Once in a lifetime experience for theSkyNet citizen scientist

Seems the story about my trip to the MRO is rather popular around the Astronomy and Science media blog'o'sphere;

Once in a lifetime experience for theSkyNet citizen scientist.

I'll be putting up a series of posts here shortly about my trip.

Wednesday, October 24, 2012

Itinerary taking shape fast

So things are taking shape fast! Plane tickets and accomodation booked.

The is itinerary coming together. So there will be a little bit of driving. About 17 hours round trip. So what is it all about? Its all about going to the SKA, here;

View Larger Map

And talking to the scientists and engineers! I have a few questions now, mostly about the data, lets start with these;

How much of a difference it makes to put the array in a relatively isolated area like Murchinson?

Whats the comparitive S/N numbers?

How many Antennas, LNA and receivers?

How are they comapring the data from those receivers?

Whats the effective gain of a single array, vesus the whole array versus a single Antennas, LNA and receiver?

Is this pahsed to drive direction?

How to shuffle that volume data around?

How is the data going to be processed?

How is the data going to be used?

How is the data going to be stored for reuse?

There are so many pieces of the puzzle that I haven't seen yet. You can see this is only scratching the surface!

I suppose the big question for TheSkyNet crunching public is how can we help? =D