Saturday, January 26, 2013

eliminate serial mouse detection in windows if using serial dongle in debugging


(quotes)

NOTE:  If you boot Windows with your ThunderBolt connected to the Com
port, Windows will think it is a serial mouse and grab the port.  It
can lead to some interesting Windows behavior as the T-Bolt outputs
data.

Easy fix. Add the following to your "Boot.ini" file. Obviously, the "x" stands for the COM port you are using.

NoSerialMice:COMx

(end quotes)

I'm not sure who typed the above text, the quote style was hard to
understand... Might've been some combination of Joe Gray, John Lofgren,
and/or someone who signs as mike?

Anyway... Here's my $0.02:

Windows Vista / 7 doesn't use

"boot.ini"

... do this instead:

Click on start --> In the search box, type in regedit
Registry editor windows opens... Navigate to the location:
HKEY_LOCAL_MACHINE
--> SYSTEM
--> CurrentControlSet
--> Services
--> sermouse
In the right hand, you'll see stuff like:

(default)
DisplayName
etc. etc. etc.

There should be a "dword (32bit) value" titled:

"start"

Set the value of this to: 00000004

If you do not see "start" use the following steps:

Right click on the (white) blank space
(below the default, displayname, etc.)

After right click to get context menu, click "New"
... a sub-menu will expand:
Select the option for:
"dword 32-bit value"

Now, give this value the name "start"

Right click to select "modify"

It should have the value: 00000004

Restart the computer

You're done 

The mouse will no longer freak out, and your GPS (timing mode, TSIP,
NMEA, or otherwise) or other RS-232 device will now work normally and
not be detected as mouse, make cursor jump strangely, etc.

Hope someone finds this useful,
Sarah

Thursday, January 24, 2013

rpm and other tricks for SUSE / Redhat

This came up in the course of looking @ a meego posting.  Looks like a handy trick to remember.

cpio create / extract is also handy, but this is a list from the output of an RPM

rpm2cpio umms-plugins-tv.rpm | cpio -idmv

Sunday, January 20, 2013

smali format

disassembly format for android DEX files

http://code.google.com/p/smali/

grep references



http://www.thegeekstuff.com/2009/03/15-practical-unix-grep-command-examples/

http://www.thegeekstuff.com/2011/10/grep-or-and-not-operators/

Wednesday, January 9, 2013

ipcop port forwarding

From various sources:

IPCop 2.0.1 port forwarding might not work:

From Brandon Cherry


Hello, I have been using IPCop since the 1.3 days though I have never 
had a need to post to this list before. I recently upgraded to the 2.0.6 
version of IPCop. I put the box into production after everything checked 
out.

The other day I had to add a new port forward with a new alias. I know 
one of the new things in this version is the ability to name the aliases 
which I did not originally use. Adding the alias went fine. It was when 
I tried to forward ports using the new alias that I encountered a problem.

I noticed that not all of my port forwards get applied to iptables, 
though it showed up under "Firewall Rules". I quickly restored a backup 
I had made before changing anything. I tried to replicate the situation 
in development and noticed the same behavior.

Basically what happens is, if you do not name your aliases, then IPCop 
will store Alias X (where X is a number) in the file 
/var/ipcop/firewall/config. If you name the alias, the name gets stored 
in that file. When you add an alias that might be in the middle of your 
IP range, then all of the port forwarding rules do not get applied to 
anything that has an alias number equal to or higher than the new alias. 
You end up with two aliases with the same number and the iptables rules 
do not get applied.

My temporary fix was to name all of my aliases. I apologize if I missed 
something, but I did searched around and didn't see anything reported on 
this issue. Can you duplicate this? Has anyone ran into this before?
-- Brandon Cherry
Access to network during bringup: from example about setting static routes
Executing: nano /etc/rc.d/rc.event.local
Then append this by copying and pasting into  rc.event.local:

     if [ ${1} == "network" -a ${2} == "up" ]; then

          /sbin/route add -net  10.0.0.0  netmask 255.255.255.0 gw 10.1.1.1
     fi

Osmar Gonzalez

Wednesday, January 2, 2013

Ntp on the Raspberry pi



http://www.talkunafraid.co.uk/2012/12/the-ntpi-accurate-time-with-a-raspberry-pi-and-venus638flpx/

Includes building the source to reconfigure the use of the Pi serial port, besides building a time server with the pi.


The ntpi: accurate time with a Raspberry Pi and Venus638FLPx


One of the things I’ve always loved to tinker with is time sources and synchronization. Typically this has been tied to sensible things like the Network Time Protocol and designing and maintaining time distribution systems for broadcast networks. Lately though I’ve been toying with ‘real’ time sources – GPS and MSF broadcasts. This is a quick tutorial on how to set up a Raspberry Pi, which at only a few watts makes for an economical time server, to talk to a Venus 638FLPx GPS receiver (available from Sparkfun on a suitable breakout board here).
It’s worth noting that the GPS chip in question is not really ideal for timing applications. There are nicer boards for this purpose. But the great thing is that because most of these things are pretty standard, almost all this guide will still work. Venus do make an IC, the 638LPx-T, which is a variant of this chip designed for timing with an accuracy of plus/minus 30us, but I can’t find that on a breakout board and I had the FLPx board spare from a UAS platform.
The basic requirements for a GPS time source/server are:
  • GPS module which outputs NMEA strings on serial and has a 1PPS output
  • Computer with GPI pin for 1PPS and serial connectivity running Linux
  • GPS antenna in a place that can see a good chunk of sky with a feed back to the module
The pinout on the Venus board has serial RX/TX, +3.3V, GND and PPS. For my timeserver I’m using the Raspberry Pi – the GPI to use is pin 23 on the headers, RX goes to TX and TX goes to RX also on the header, and the header power for 3V3 works perfectly for powering the module. I used an Adafruit Pi Cobbler to breadboard this, but will use a Ciseco Slice of Pi board to make something a bit more solid later. It’s pretty simple to hook up, in any case.
The tricky bit comes with the software. Let’s talk about how GPS time sourcing works.
The GPS satellites rely on highly accurate timing, and broadcast UTC time information as part of their signals. The difference in the timestamps is what, largely, allows your receiver to figure out where you are. If you know where you are, though, you can use those timestamps to come up with a very accurate fix for time.
The NMEA strings that come off the GPS describe all sorts of things. They look a bit like this:
pi@ntpi ~ $ cat /dev/gps0
$GPGGA,201705.000,5644.4848,N,00142.3529,W,1,10,0.9,64.4,M,49.0,M,,0000*75
$GPGLL,5644.4848,N,00142.3529,W,201705.000,A,A*43
$GPGSA,A,3,07,26,08,19,15,05,09,21,18,24,,,1.5,0.9,1.2*3B
$GPZDA,201705.000,29,12,2012,00,00*5E
They’re a bit obscure but they have the time encoded into them along with things like how many satellites are used in the solution, velocity/heading, and so on. The first chunk, $GPGGA for instance, is a preamble for each string – the last three characters are used to refer to a string of that type, eg GGA.
Sadly this won’t get us a very accurate reference. Let’s look at what the PPS looks like, for starters, with an oscilloscope:PPS pulses

We can see quite clearly these are small, 5ms pulses exactly once a second. Great! So how about those NMEA strings being sent over serial?
PPS versus NMEA serial
We can see in the top half of this trace a full NMEA transmission occurring just after (1.18ms) the PPS pulse – but the NMEA transmission is huge! And if we follow it, we see it move around, too.
PPS at the front of a NMEA burst

This is a zoomed in view of a PPS pulse against the NMEA transmission (1.6ms after the pulse, this time – plenty of variance). This was taken with the GPS in ‘send NMEA in sync with PPS’ mode!
So if we want to get our device accurate we need to use PPS. But if we just use PPS, we don’t know which second we’re in! So we have to use both. Fortunately, ntpd will manage this for us.
Diving back to the software, then – we need a kernel that can deal with the PPS pulses on our GPI port. Let’s install one:
git clone https://github.com/davidk/adafruit-raspberrypi-linux-pps.git
cd adafruit-raspberrypi-linux-pps/
sudo mv /boot/kernel.img /boot/kernel.img.orig
sudo cp kernel.img /boot
sudo mv modules/* /lib/modules
sudo sh -c "echo 'pps-gpio' >> /etc/modules"
We need to disable the default usage of the Pi’s serial, which is to provide a tty. Open /boot/cmdline.txt and remove all elements referring to ttyAMA0. Mine looks like this:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Next, open /etc/inittab and comment this line out:
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
We also want to configure udev to put our GPS module and PPS where ntpd will expect it to be:
sudo nano /etc/udev/rules.d/80-gps-to-ntp.rules

# Change MODE of ttyAMA0 so it is readable by NTP and provide a symlink to
# /dev/gps0
KERNEL=="ttyAMA0", SUBSYSTEM=="tty", DRIVER=="", SYMLINK+="gps0", MODE="0666"
# Symlink /dev/pps0 to /dev/gpspps0
KERNEL=="pps0", SUBSYSTEM=="pps", DRIVER=="", SYMLINK+="gpspps0", MODE="0666"
Next we’re going to install then remove ntpd – we’ll be back with an updated version.
sudo apt-get install ntp
sudo apt-get remove ntp
sudo apt-get install libcap-dev
Time to install and compile a PPS-enabled ntpd.
wget http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p340.tar.gz
tar zxf ntp-dev-4.2.7p340.tar.gz
cd ntp-dev-4.2.7p340/
./configure --prefix=/usr --enable-all-clocks --enable-parse-clocks --enable-SHM --enable-debugging --sysconfdir=/var/lib/ntp --with-sntp=no --with-lineeditlibs=edit --without-ntpsnmpd --disable-local-libopts --disable-dependency-tracking --enable-ipv6 && make && sudo make install
Now we’ve got all this we need to reboot to load the new kernel:
sudo reboot
First, we can verify that we can see the NMEA sentences:
cat /dev/gps0
You should see NMEA strings! Ctrl+C to kill it. Next, let’s test the PPS.
pi@ntpi ~ $ dmesg | grep pps
[    0.000000] Linux version 3.1.9adafruit-pps+ (davidk@bender) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #21 PREEMPT Sun Sep 2 10:57:58 PDT 2012
[    1.148909] usb usb1: Manufacturer: Linux 3.1.9adafruit-pps+ dwc_otg_hcd
[   14.707851] pps_core: LinuxPPS API ver. 1 registered
[   14.712724] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[   14.728437] pps pps0: new PPS source pps-gpio.-1
[   14.731832] pps pps0: Registered IRQ 108 as PPS source
Looks like we’re good to go. Check the pps-utils package if you need to verify more completely.
Next up: telling ntp about this shiny new local clock!
We need to do one thing first – if your local network has a DHCP server that announces time servers, you want to use your local NTP config despite this. You need to edit /etc/init.d/ntp and comment the following lines out:
#if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
#       NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
#fi
Open up /etc/ntp.conf and adjust it to taste. The following stanza should get you up and running:
server 127.127.20.0 mode 24 minpoll 3 maxpoll 4 iburst true prefer
fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 flag4 1 time2 0.093
The settings here are documented here and can be configured to suit your module. The time2 value may need to be larger (0.4 or so), and you may want to keep or remove the existing servers configured in ntp.conf – or just reconfigure them to be geographically local. You can get an idea of the time2 offset by adding 128 to whatever mode value you’re using, then looking at the timings in /var/log/ntpstats/clockstats after a ntpd restart. Pick the time offset for the first NMEA string seen and there’s your number.
Restart ntpd, wait a few minutes for it all to settle down, and verify things are working:
pi@ntpi ~ $ ntptime
ntp_gettime() returns code 0 (OK)
  time d489d596.2b0cfe14  Sat, Dec 29 2012 20:48:22.168, (.168167784),
  maximum error 2000 us, estimated error 1 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 2.518 us, frequency 79.473 ppm, interval 1 s,
  maximum error 2000 us, estimated error 1 us,
  status 0x2007 (PLL,PPSFREQ,PPSTIME,NANO),
  time constant 3, precision 0.001 us, tolerance 500 ppm,
pi@ntpi ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l    8    8  377    0.000    0.002   0.004
+ns0.luns.net.uk 157.44.176.4     2 u   63   64   17   44.161    3.389   0.709
-ntp.oceanmediag 192.93.2.20      2 u    5   64   37   34.806    2.048   0.585
+dns1.rmplc.co.u 193.62.22.74     2 u   63   64   17   36.375    2.488   0.282
*mail1.itdojo.or 10.10.120.2      2 u   56   64   17   51.280    3.977   0.270
pi@ntpi ~ $ ntptrace
localhost: stratum 1, offset 0.000001, synch distance 0.001090, refid 'GPS'
Note the o before GPS_NMEA(0) in ntpq -p – this indicates the PPS is being used. If you don’t have the PPS enabled your time will kinda suck, as we saw a bit with the scope traces. To illustrate this, here’s a comparison of system performance between NMEA-only and PPS.
ntp_kernel_pll_off-day ntp_offset-dayYou really, really want to make sure your system is using the PPS, is what I’m getting at.
Another thing I ran into was the GPS reporting the wrong time or not reporting its timing offset – just ensure you have enabled the GPZDA statement to avoid this. Symptoms of this can include huge offsets and being marked as a falseticker (x) in peer lists of other peers. Just make sure your module is configured properly. This is what I did to configure my module:
  • Enabled position pinning
  • Disabled all NMEA strings except for GGA, GSA, GLL and ZDA
  • Set update rate to 1Hz and output sync to UTC
  • Set baud rate to 9600 (higher is not better!)
This seems to work quite well, and I’m very happy with the performance given the low cost of the solution – it just needs popping in a box and it’ll be a nice stable time reference for my home network. I’m still interested in sourcing time from MSF with a receiver but we have quite poor reception of the MSF signal here, so we’ll see if that’s even feasible with the Pi. Given how important it is to maintain accurate time in broadcast networks, especially with external programme sources, this is a really nice thing to have gotten working and documented. Kudos to the guys over at this thread on the Raspberry Pi forums who did a lot of the legwork figuring this all out!