XMEN BLOGGER: Nikon D7000
Showing posts with label Nikon D7000. Show all posts
Showing posts with label Nikon D7000. Show all posts

Thursday, January 05, 2017

Nikon D7000 - Raspberry Pi as an Access Point to control your camera w/Raspbian


From:
http://dslrdashboard.info/
http://digicamcontrol.com/doc/



You need:

- Raspberry Pi 2B, because it has 4 USB port, and I need it to control my Nikon camera and my Celestron teelescope (if you need more info, check this) with Raspbian installed.
- USB Wifi dongle compatible.
- External battery (5V output) to do power to your Raspberry Pi.
- USB cable (USB to mini-USB), to connect raspberry pi to Nikon D7000 camera.

First step:

- Install Raspbian (if you have doubts, please check raspbian.org.

- Update your Raspberry Pi from repositories:

pi@raspsrv $ sudo apt-get update
pi@raspsrv $ sudo apt-get upgrade

- And install rpi-update:

pi@raspsrv $ sudo apt-get install rpi-update
pi@raspsrv $ sudo rpi-update

Please, reboot when finish!!

- Troubleshooting... (If needed)

pi@raspsrv $ sudo apt-get install ca-certificates

pi@raspsrv $ sudo apt-get install ntpdate
pi@raspsrv $ sudo ntpdate -u ntp.ubuntu.com

Second step:

Configure your Raspberry Pi as an Acces Point.

1. Install all that you need:

pi@raspsrv $ sudo apt-get install hostapd isc-dhcp-server

# Probably you don't need install this:
pi@raspsrv $ sudo apt-get install iptables-persistent

If you have a non-common WiFi adapter, you can update hostapd driver from adafruit...

pi@raspsrv $ wget http://adafruit-download.s3.amazonaws.com/adafruit_hostapd_14128.zip
pi@raspsrv $ unzip adafruit_hostapd_14128.zip

pi@raspsrv $ sudo mv /usr/sbin/hostapd /usr/sbin/hostapd.ORIG
pi@raspsrv $ sudo mv hostapd /usr/sbin
pi@raspsrv $ sudo chmod 755 /usr/sbin/hostapd

2. Edit your interfaces file to configure wlan0 adapter:

pi@raspsrv $ cat /etc/network/interfaces
auto lo

iface lo inet loopback
iface eth0 inet dhcp
#iface eth0 inet static
# address 192.168.0.190
# netmask 255.255.255.0
# gateway 192.168.0.1

allow-hotplug wlan0
#iface wlan0 inet manual
#wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
#iface default inet dhcp
iface wlan0 inet static
address 192.168.5.1
netmask 255.255.255.240
gateway 192.168.0.1

pre-up iptables-restore < /etc/iptables.ipv4.nat

3. Edit your DHCP daemon config file:

pi@raspsrv $ cat /etc/dhcp/dhcpd.conf
#
# Sample configuration file for ISC dhcpd for Debian
#
#

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# option definitions common to all supported networks...
##option domain-name "example.org";
##option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {
# range 10.254.239.10 10.254.239.20;
# option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

#subnet 10.254.239.32 netmask 255.255.255.224 {
# range dynamic-bootp 10.254.239.40 10.254.239.60;
# option broadcast-address 10.254.239.31;
# option routers rtr-239-32-1.example.org;
#}

# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
# range 10.5.5.26 10.5.5.30;
# option domain-name-servers ns1.internal.example.org;
# option domain-name "internal.example.org";
# option routers 10.5.5.1;
# option broadcast-address 10.5.5.31;
# default-lease-time 600;
# max-lease-time 7200;
#}

# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

#host passacaglia {
# hardware ethernet 0:0:c0:5d:bd:95;
# filename "vmunix.passacaglia";
# server-name "toccata.fugue.com";
#}

# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
# hardware ethernet 08:00:07:26:c0:a5;
# fixed-address fantasia.fugue.com;
#}

# You can declare a class of clients and then do address allocation
# based on that. The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

#class "foo" {
# match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}

#shared-network 224-29 {
# subnet 10.17.224.0 netmask 255.255.255.0 {
# option routers rtr-224.example.org;
# }
# subnet 10.0.29.0 netmask 255.255.255.0 {
# option routers rtr-29.example.org;
# }
# pool {
# allow members of "foo";
# range 10.17.224.10 10.17.224.250;
# }
# pool {
# deny members of "foo";
# range 10.0.29.10 10.0.29.230;
# }
#}

subnet 192.168.5.0 netmask 255.255.255.240 {
range 192.168.5.5 192.168.5.10;
option broadcast-address 192.168.5.15;
option routers 192.168.5.1;
default-lease-time 600;
max-lease-time 7200;
option domain-name "wifi.local";
option domain-name-servers 8.8.8.8, 8.8.4.4;
}

4. Edit your DHCP server config file:

pi@raspsrv / $ cat /etc/default/isc-dhcp-server
# Defaults for isc-dhcp-server initscript
# sourced by /etc/init.d/isc-dhcp-server
# installed at /etc/default/isc-dhcp-server by the maintainer scripts

#
# This is a POSIX shell fragment
#

# Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf).
#DHCPD_CONF=/etc/dhcp/dhcpd.conf

# Path to dhcpd's PID file (default: /var/run/dhcpd.pid).
#DHCPD_PID=/var/run/dhcpd.pid

# Additional options to start dhcpd with.
# Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead
#OPTIONS=""

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
##INTERFACES=""
INTERFACES="wlan0"

5. Edit your host APD config file:

pi@raspsrv / $ cat /etc/hostapd/hostapd.conf
interface=wlan0
driver=nl80211
#driver=rtl871xdrv
ssid=MyPi
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=Raspb3rry
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

6. Edit your host APD daemon config file:

pi@raspsrv / $ cat /etc/default/hostapd
# Defaults for hostapd initscript
#
# See /usr/share/doc/hostapd/README.Debian for information about alternative
# methods of managing hostapd.
#
# Uncomment and set DAEMON_CONF to the absolute path of a hostapd configuration
# file and hostapd will be started during system boot. An example configuration
# file can be found at /usr/share/doc/hostapd/examples/hostapd.conf.gz
#
#DAEMON_CONF=""
DAEMON_CONF="/etc/hostapd/hostapd.conf"

# Additional daemon options to be appended to hostapd command:-
# -d show more debug messages (-dd for even more)
# -K include key data in debug messages
# -t include timestamps in some debug messages
#
# Note that -B (daemon mode) and -P (pidfile) options are automatically
# configured by the init.d script and must not be added to DAEMON_OPTS.
#
#DAEMON_OPTS=""

7. Edit your SYSCTL config file:

pi@raspsrv / $ cat /etc/sysctl.conf
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additonal system variables
# See sysctl.conf (5) for information. #

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console kernel.printk = 3 4 1 3

###############################################################
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

# rpi tweaks
vm.swappiness=1
vm.min_free_kbytes = 8192

8. Add a iptables file:

pi@raspsrv / $ cat /etc/iptables.ipv4.nat
# Generated by iptables-save v1.4.14 on Thu Nov 26 08:15:51 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m comment --comment "Accept all ingoing" -j ACCEPT
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
-A OUTPUT -m comment --comment "Accept all outgoing" -j ACCEPT
COMMIT
# Completed on Thu Nov 26 08:15:51 2015
# Generated by iptables-save v1.4.14 on Thu Nov 26 08:15:51 2015
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o wlan0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu Nov 26 08:15:51 2015

9. Add a iptables file:

pi@raspsrv / $ cat /etc/iptables.ipv4.nat
pi@raspsrv $ sudo service hostapd start
pi@raspsrv $ sudo service isc-dhcp-server start

pi@raspsrv $ sudo service hostapd status
pi@raspsrv $ sudo service isc-dhcp-server status

pi@raspsrv $ sudo update-rc.d hostapd enable
pi@raspsrv $ sudo update-rc.d isc-dhcp-server enable

Third step

- Download, Install and Confiure DSLR Dashboard server (ddserver)

1. Clone GitHub reposiroty and compile:
pi@raspsrv $ pwd
/home/pi
pi@raspsrv $ git clone git://github.com/hubaiz/DslrDashboardServer package/DslrDashboardServer
pi@raspsrv $ cd package/DslrDashboardServer
pi@raspsrv $ sudo make menuconfig

pi@raspsrv $ sudo apt-get install build-essential pkg-config libusb-1.0-0-dev
pi@raspsrv $ sudo g++ -Wall src/main.cpp src/communicator.cpp `pkg-config --libs --cflags libusb-1.0` -lpthread -lrt -lstdc++ -o ddserver

2. Move to /usr/local/bin:

pi@raspsrv $ cd /home/pi/package
pi@raspsrv $ sudo mv DslrDashboardServer /usr/local/bin/DslrDashboardServer

/usr/local/bin/DslrDashboardServer/ddserver

- Create and add ddserver script on startup

pi@raspsrv /etc/init.d $ cat ddserver.sh
#!/bin/sh

### BEGIN INIT INFO
# Provides: ddserver
# Required-Start: $all
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: DslrDashboardServer daemon
# Description: Access and Control DSLR Cameras
### END INIT INFO

DIR=/usr/local/bin/DslrDashboardServer
DAEMON=$DIR/ddserver
DAEMON_NAME=ddserver
DAEMON_OPTS=""
DAEMON_USER=root

PIDFILE=/var/run/$DAEMON_NAME.pid

. /lib/lsb/init-functions

do_start () {
log_daemon_msg "Starting system $DAEMON_NAME daemon"
start-stop-daemon --start --background --pidfile $PIDFILE --make-pidfile --user $DAEMON_USER --chuid $DAEMON_USER --startas />$DAEMON -- $DAEMON_OPTS
log_end_msg $?
}
do_stop () {
log_daemon_msg "Stopping system $DAEMON_NAME daemon"
start-stop-daemon --stop --pidfile $PIDFILE --retry 10
log_end_msg $?
}

case "$1" in
start|stop)
do_${1}
;;
restart|reload|force-reload)
do_stop
do_start
;;
status)
status_of_proc "$DAEMON_NAME" "$DAEMON" && exit 0 || exit $?

;;
*)
echo "Usage: /etc/init.d/$DAEMON_NAME {start|stop|restart|status}"
exit 1
;;
esac
exit 0

pi@raspsrv $ cp -p ddserver.sh /etc/init.d
pi@raspsrv $ sudo chmod u+x /etc/init.d/ddserver.sh
pi@raspsrv $ sudo update-rc.d /etc/init.d/ddserver.sh defaults

pi@raspsrv $ cp your_script /etc/init.d/
pi@raspsrv $ sudo chmod u+x /etc/init.d/your_script
pi@raspsrv $ sudo update-rc.d /etc/init.d/your_script defaults

Tuesday, January 03, 2017

Nikon D7000 - Clone Nikon ML-L3 IR Remote and Emulation


From: http://goughlui.com/2013/12/06/teardown-and-project-clone-nikon-ml-l3-ir-remote-and-emulation/



Teardown and Project: Clone Nikon ML-L3 IR Remote and Emulation

Users of Nikon cameras, including the D3200, have had several choices for remote triggering. The use of a wired remote is traditional, with infrared (IR) remotes being common accessories for many and Wi-Fi just becoming the latest craze.

The Product

The Nikon D3200 is compatible with the Nikon ML-L3 IR remote. A quick look on eBay reveals a large number of clone (compatible, non OEM) remotes available for as little as AU$1.20 posted. That includes the CR2025 battery as well. For that price, you’d be silly to go without one (or two, or three)!

I’m not sure what the original ML-L3 is made of, but this is very much like the cheap “flat” remotes provided with many TV tuners. It is constructed of a single PCB, using a single CR2025 coin battery. The buttons are made by carbon-coated dome-formed thick self-adhesive plastic sheet which sits over the PCB interlocking finger pattern traces. It’s not particularly glorious or durable with repeated use, but that’s the way things are.

Tearing it apart reveals an extremely simple construction. The PCB underside is marked with KD301B-A054-002 and FS3423. The plastic mold is marked with KD301B. The PCB utilizes a single IC, capacitor and IR LED. There are no resistors, or even ceramic oscillators (455khz commonly seen on IR remotes, as 455khz/12 = 37.91khz).

here’s no real information I can find on the IC, it’s marked PRT-P08 TX0917. This IC must be able to generate the IR code pattern (including the timing) and limit the current to the LED on the on-phase. I can’t say all clone remotes would use this chip – others may opt for chip-on-board construction.

Tracing the very-simple traces gives me the following schematic:



Simple ain’t it? You could probably alter the circuit board to generate the IR code on other triggers. I don’t know what the unconnected pins are used for – or if they are used at all. Maybe it’s programmable? Maybe there are other modes?

The remote itself fires off the D3200 very reliably, and it’s cheap. I can’t complain of the quality given the price, but I wouldn’t want to rely on having just one in an emergency. Infrared trigger isn’t as “reliable” as wired triggering, since you do need to have a working battery and be within range of the sensor. The sensor has to be activated through the menus, and the camera will time out and sleep the sensor if it’s not been used for a while, so the applications are limited. But it’s nice since it involves no touching the camera (after set-up) and no possibility of conducting any vibrations through trigger cables.

Analyzing the Code

It’s not the first time I’ve worked on emulating infrared remotes. I had posted two videos earlier, which are quite long which does show my previous work (although isn’t easy to follow from the video). I think it’s much more illustrative to write about it instead.

Incidentally, this remote proves to be one of the simplest to emulate.

The first thing you need to do is “record” the signal from the remote. You can do this directly by reading the voltage across the LED (which is most direct, and gives you the raw data including the carrier frequency of the IR system). Another way is to use an IR receiver like the ones used in TV tuners and probe with TTL output (high for presence of 38khz IR carrier, low for absence of 38khz IR carrier).

An IR receiver from a TV tuner.

The method with the IR receiver was used in my former emulation attempts, but it’s not ideal as the sensor may not be able to give you data for non-38khz IR systems. Most of them are 38khz, but there are some using other rates.

IR transmission mostly involves the keying on-and-off of a 38khz signal. The use of 38khz allows for the filtering of “steady” IR background and general noise.

It’s important to capture the IR pulse train using an oscilloscope, high rate data-logger or something similar. I used my Poscope basic2. I cannot recommend users to buy this product, as it only supports Windows, triggering has no hold-off options and is hit and miss, there’s no anti-aliasing filter, the software is pretty broken in Recorder mode when recording at high rates, the data is recorded in a format needing conversion by their tools and it is very limited in sampling rate. I have a heap of trouble with it in general under Windows 7, although older versions of software on Windows XP with specific USB controllers can work semi-reliably. But with enough patience, even something this basic like this is sufficient.

The first thing to understand is that IR remotes tend to send the same code over and over when the button is depressed. In this case, the remote actually sends its code three times over – here we can see just one iteration which takes about 100ms, which repeats.

Most of the time is with the IR LED off, the code itself is very simple. Re-acquiring zoomed in (noting polarity is due to the way the connections were made):

We can see the remote starts with a 2ms burst of 38khz, followed by 28ms rest, 0.5ms burst, 1.5ms rest, 0.5ms burst, 3.5ms rest, 0.5ms burst, 63.5ms rest. That is the IR code we need to emulate to make it “work”. Note that slight timing and frequency differences are expected – say different battery levels and component tolerances.

Take it from me, it’s 38khz – I looked closely into it.

Making it Work

The first thing you need to emulate something like this is a suitable IR LED. Instead of buying it off the shelf, I decided to pinch one from a “useless” remote I had from my RTL-SDR purchases. I’m never going to use the remote – so why waste the LED?

Having extracted the LED, I have to ensure its safety. The voltage drop of my IR LED is about 1v at 1mA, and using a 5v Arduino, I decided to go with two 680 ohm resistors in parallel for an LED current of about 12mA. LEDs like these may be capable of currents up to 20mA, but I decided to play it safe. In fact, it’ll be safe to overdrive it slightly given the low duty cycle of the remote signal.

Of course, as a lazy person, I decided to solder it to some header pins air-wire style, and then cover it with globs of hot glue.

Positive in this case is the pin on the left. I decided to plug it straight into my Arduino Mega 2560 (clone) which I had handy, but you don’t need something this powerful.

The first thing is to write the code that approximates the timing. You’ll find that you will encounter some possible issues say if you use tone() with duration, so instead, use tone() and noTone() instead.

Here is the code – I tested my code, and it does fire off my D3200:

// Nikon Remote Emulator by Gough Lui (http://goughlui.com)
// A1 = IR +
// A0 = IR -

int count=0;

void setup() {
pinMode(A0,OUTPUT);
digitalWrite(A0,LOW);
pinMode(A1,OUTPUT);
digitalWrite(A1,LOW);
}

void loop() {
// Send code three times, as the clone remote does
// Delays are tuned to account for overhead of library code.
while(count<3) {
tone(A1,38000);
delay(2);
noTone(A1);
delay(28);
tone(A1,38000);
delayMicroseconds(200);
noTone(A1);
delayMicroseconds(1500);
tone(A1,38000);
delayMicroseconds(200);
noTone(A1);
delayMicroseconds(3300);
tone(A1,38000);
delayMicroseconds(200);
noTone(A1);
delayMicroseconds(100);
delay(63);
count++;
}
}

Note that the delay timings are not as suggested by the scope capture – this is because there is overhead in the Arduino library functions which take time to execute. Instead, the times are trimmed through trial and error to result in a trace on the scope which closely mirrors the original (although slight timing deviations would be okay). You don’t need to match the original quite 100% as each remote may have slight component differences resulting in offset carrier frequencies and timing. As long as you’re within a few percent, the device should recognize the transmitted code.

The pulse train, as measured by my crappy PoScope basic2 unit looks pretty damn close to the original remote – so now I’ve got the code to trigger my camera using IR. What to do now? Well, you could make some specialized trigger system algorithmically controlled by the Arduino … it’s really up to your imagination.

Besides, now you know what to do when you want to emulate a remote :).

Nikon D7000 - Add a GPS


From: https://www.cyrozap.com/2011/08/13/diy-nikon-d5100-gps/



You need:

- Microsoft GPS-500 (or GPS-360, it has the same pinout). You can get one on eBay for $20 (and if you're lucky enought, it came with a TTL-USB cable AND Streets & Trips 2008 AND an MSN Direct Receiver).
- Shutter connecting cord for Nikon D5100 (or D7000 ;-P). They use MC-DC2 connector (mini-USB propietary connector)
- Ethernet cable that you're willing to strip (if you want, or the same Pharos GPS cable-connector).
- Kapton tape (if you want).
- 5v diode.
- Some sort of strain relief for the wires at the camera connector.
- A steady hand.

I got the pinout data for the GPS from here and the pinout data for the camera connector (with a lot of other useful info) here. Note: on the Flickr photo, read my comment for clarifying info and corrections.



 

My setup doesn't use any TTL voltage converters because the D5100 seems to be able to use the 3.3V TTL from the GPS. I may include a diode in the power line at some point to drop the voltage a little because the camera is feeding 6V to the GPS and its specs say it has a max power input of 5.5V, but it's working so far.

Basically, connect pin 5 on the GPS (the one to the right of the leftmost one when the gold contacts are facing up) to the power pin on the camera connector, pin 2 on the GPS to ground on the camera connector, and pin 3 on the GPS to TTL/Serial in on the camera connector.

  GPS PIN2 - MC-DC2 PIN3 - GND
  GPS PIN3 - MC-DC2 PIN7 - DATA (4800 TTL NMEA)
  GPS PIN5 - MC-DC2 PIN4 - +5v

EDIT: I added the diode; it dropped the voltage to about 5.0V-5.2V. I feel a bit better now.

Oh, by the way, don't connect Pin 1 (GPS Rx) to ground! I happened to do this by accident and it screwed up the serial output until I fixed the solder bridge.

This setup may work for other newish Nikon cameras, but they may not be 3.3V TTL tolerant, so YMMV.



Pharos GPS-500 & GPS-360 specs