https://rurandom.org/justintime/api.php?action=feedcontributions&user=Danny&feedformat=atomJust in Time - User contributions [en]2024-03-29T10:43:10ZUser contributionsMediaWiki 1.35.0https://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3959Voron Configuration2024-01-01T20:11:56Z<p>Danny: </p>
<hr />
<div>=== CAN Bus upgrade ===<br />
Mellow sb2040.<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].<br />
* Mellow [https://mellow.klipper.cn/#/board/fly_sb2040/ SB2040 documentation].<br />
* [https://www.reddit.com/r/VORONDesign/comments/11j6hym/help_setting_up_canbus_sb2040_utoc3_octopus_11/ reddit thread] with useful links.<br />
* More [https://github.com/Esoterical/voron_canbus explanatory git pages].<br />
<br />
<br />
Steps performed:<br />
<code>sudo /bin/sh -c "cat > /etc/network/interfaces.d/can0" << EOF<br />
allow-hotplug can0<br />
iface can0 can static<br />
bitrate 500000<br />
up ifconfig \$IFACE txqueuelen 1024<br />
EOF</code><br />
<br />
<br />
<blockquote><code>sudo wget <nowiki>https://cdn.mellow.klipper.cn/shell/can-enable</nowiki> -O /usr/bin/can-enable > /dev/null 2>&1 && sudo chmod +x /usr/bin/can-enable || echo "The operation failed"</code></blockquote><br />
<code>sudo sed -i '/^exit\ 0$/i \can-enable -d can0 -b 500000 -t 1024' /etc/rc.local</code><br />
<br />
=== Flash CAN bus ===<br />
python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 9ba2113afef3</div>Dannyhttps://rurandom.org/justintime/index.php?title=PC_configurations&diff=3958PC configurations2023-06-20T10:58:17Z<p>Danny: information added to support CR3 files in Ubuntu</p>
<hr />
<div>Note that this page is not directly related to any MCU project. Since I'm installing quite a number of different linux configurations on systems, this page contains some notes on how they've been configured.<br />
<br />
==Eclipse==<br />
[http://hanynowsky.wordpress.com/2012/05/08/eclipse-ides-ubuntu-integrated-menus-hack/ This page] describes how to hack a shared library to allow Unity menu integration of eclipse. The gist of it:<br />
cd /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/menuproxies && sudo sed -i 's/Eclipse/Xclipse/' libappmenu.so<br />
<br />
To change the appearance of tool tips in unity to be legible within eclipse, follow [http://askubuntu.com/questions/70599/how-to-change-tooltip-background-color-in-unity these instructions]. Gist:<br />
sudo gedit /usr/share/themes/Radiance/gtk-2.0/gtkrc<br />
and use #000000 for tooltip_fg_color and #f5f5b5 for tooltip_fg_color.<br />
<br />
==Media PC==<br />
* Ubuntu 10.04<br />
* mythtv from synaptic<br />
* mythweb<br />
* phpmyadmin<br />
* unsuccessful move to new Nvidia graphics card (FIXME)<br />
* tv_grab_nl_py script<br />
* trying to slow down GPU fan through lm-sensors, needs kernel option to run it87 driver (as descriped [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/418246 here])<br />
<br />
==Laptop==<br />
<br />
Adapt /etc/init.d/ondemand to switch to 'conservative' instead of 'ondemand'.<br />
<br />
Citrix receiver setup on [https://help.ubuntu.com/community/CitrixICAClientHowTo this page].<br />
<br />
if needed add the local script to the init sequence with <br />
sudo update-rc.d local defaults<br />
<br />
<b>The following is not needed anymore after a clean install of 13.04</b><br />
<br />
See this thread: http://ubuntuforums.org/showthread.php?t=1747226<br />
<br />
To get touch interface to work again on a Toshiba M700, add the following to /etc/init.d/local<br />
xsetwacom set "Serial Wacom Tablet touch" touch on<br />
xsetwacom set "Serial Wacom Tablet touch" Gesture on<br />
<br />
By default the screen brightness is very low when logging in. I therefore also add the following to the same file<br />
echo 7 > /sys/class/backlight/acpi_video0/brightness<br />
<br />
==Desktop==<br />
<br />
=== Getting CR3 files recognized ===<br />
[https://gitlab.gnome.org/GNOME/shotwell/-/issues/199] says image/x-canon-cr3 should be the mime type<br />
mimetype -D <file><br />
tells me how it got to identify a specific file type.<br />
<br />
adding /etc/mime.types had no immediate effect, maybe rebooting works.<br />
<br />
===Graphics driver performance===<br />
High compiz cpu load? Verify that the graphics driver is not the gallium (software) renderer ("System Settings"->"Details"). Install xserver-xorg-video-intel if it is.<br />
<br />
adapt /etc/nsswitch.conf if browsers start to become slow in dns lookup.<br />
<br />
[http://www.iheartubuntu.com/2012/02/install-canon-printer-for-ubuntu-linux.html this page] shows how to install a canon MP640 under ubuntu. The gist is:<br />
<br />
<pre><br />
sudo add-apt-repository ppa:michael-gruz/canon<br />
sudo apt-get update<br />
sudo apt-get install cnijfilter-mp640series<br />
</pre><br />
===Install inconsolata===<br />
Easiest by installing [https://launchpad.net/typecatcher TypeCatcher]. This install inconsolate from Google fonts, making sure that there is a decent (truly monospaced) bold version as well.<br />
<br />
===Server===<br />
[https://ubuntuforums.org/showthread.php?t=2320889 Dovecot issue with smb pam]:<br />
<pre><br />
dpkg --purge libpam-winbind libpam-smbpass<br />
</pre></div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3957Voron Configuration2023-05-05T22:35:11Z<p>Danny: </p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].<br />
* Mellow [https://mellow.klipper.cn/#/board/fly_sb2040/ SB2040 documentation].<br />
* [https://www.reddit.com/r/VORONDesign/comments/11j6hym/help_setting_up_canbus_sb2040_utoc3_octopus_11/ reddit thread] with useful links.<br />
* More [https://github.com/Esoterical/voron_canbus explanatory git pages].<br />
<br />
<br />
<br />
Steps performed:<br />
<code>sudo /bin/sh -c "cat > /etc/network/interfaces.d/can0" << EOF<br />
allow-hotplug can0<br />
iface can0 can static<br />
bitrate 500000<br />
up ifconfig \$IFACE txqueuelen 1024<br />
EOF</code><br />
<br />
<br />
<blockquote><code>sudo wget <nowiki>https://cdn.mellow.klipper.cn/shell/can-enable</nowiki> -O /usr/bin/can-enable > /dev/null 2>&1 && sudo chmod +x /usr/bin/can-enable || echo "The operation failed"</code></blockquote><br />
<code>sudo sed -i '/^exit\ 0$/i \can-enable -d can0 -b 500000 -t 1024' /etc/rc.local</code></div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3956Voron Configuration2023-04-30T22:35:01Z<p>Danny: Add link and steps performed so far</p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].<br />
* Mellow [https://mellow.klipper.cn/#/board/fly_sb2040/ SB2040 documentation].<br />
* [https://www.reddit.com/r/VORONDesign/comments/11j6hym/help_setting_up_canbus_sb2040_utoc3_octopus_11/ reddit thread] with useful links.<br />
<br />
<br />
<br />
Steps performed:<br />
<code>sudo /bin/sh -c "cat > /etc/network/interfaces.d/can0" << EOF<br />
allow-hotplug can0<br />
iface can0 can static<br />
bitrate 500000<br />
up ifconfig \$IFACE txqueuelen 1024<br />
EOF</code><br />
<br />
<br />
<blockquote><code>sudo wget <nowiki>https://cdn.mellow.klipper.cn/shell/can-enable</nowiki> -O /usr/bin/can-enable > /dev/null 2>&1 && sudo chmod +x /usr/bin/can-enable || echo "The operation failed"</code></blockquote><br />
<code>sudo sed -i '/^exit\ 0$/i \can-enable -d can0 -b 500000 -t 1024' /etc/rc.local</code></div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3955Voron Configuration2023-04-30T21:10:18Z<p>Danny: Adding steps performed so far</p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].<br />
* Mellow [https://mellow.klipper.cn/#/board/fly_sb2040/ SB2040 documentation].<br />
<br />
<br />
<br />
Steps performed:<br />
<code>sudo /bin/sh -c "cat > /etc/network/interfaces.d/can0" << EOF<br />
allow-hotplug can0<br />
iface can0 can static<br />
bitrate 500000<br />
up ifconfig \$IFACE txqueuelen 1024<br />
EOF</code><br />
<br />
<br />
<blockquote><code>sudo wget <nowiki>https://cdn.mellow.klipper.cn/shell/can-enable</nowiki> -O /usr/bin/can-enable > /dev/null 2>&1 && sudo chmod +x /usr/bin/can-enable || echo "The operation failed"</code></blockquote></div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3954Voron Configuration2023-03-02T23:38:32Z<p>Danny: /* CAN Bus upgrade */</p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].<br />
* Mellow [https://mellow.klipper.cn/#/board/fly_sb2040/ SB2040 documentation].</div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3953Voron Configuration2023-03-02T23:38:18Z<p>Danny: /* CAN Bus upgrade */</p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].<br />
* Mellow [https://mellow.klipper.cn/#/board/fly_sb2040/ SB2040 documentation]</div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3952Voron Configuration2023-03-02T23:27:22Z<p>Danny: </p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info, but more noise than signal.<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].</div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3951Voron Configuration2023-03-02T22:42:40Z<p>Danny: /* CAN Bus upgrade */</p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device<br />
* Some experiences and designs in a github repo [https://github.com/cruiten/Voron-Related/tree/main/CANbus/Documentation here].</div>Dannyhttps://rurandom.org/justintime/index.php?title=Voron_Configuration&diff=3950Voron Configuration2023-02-14T17:12:07Z<p>Danny: Created page with "=== CAN Bus upgrade === * [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info * Klipper [https://www.klipper3d.org/CANBU..."</p>
<hr />
<div>=== CAN Bus upgrade ===<br />
<br />
* [https://forum.vorondesign.com/threads/can-bus-upgrade-information-and-sources.323/ This thread] has info<br />
* Klipper [https://www.klipper3d.org/CANBUS.html#usb-to-can-bus-bridge-mode supports] using the BTT Octopus as a USB-to-CAN device</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3949Notes on sonoff, shelly, tasmota2021-08-02T21:13:43Z<p>Danny: </p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|<br />
* [https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
* [https://github.com/njh/sonoff-ota-flash-cli Bash script] for fashing Sonoff, including Mini<br />
* Need physical access (press button) to go flash<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
* [https://templates.blakadder.com/sonoff_DUALR3.html templates and flashing instructions]<br />
* Configure [https://tasmota.github.io/docs/Blinds-and-Shutters/ as shutter]<br />
* Need wired connection for firmware flash<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
* [https://github.com/yaourdt/mgos-to-tasmota OTA] flashing<br />
* can be flashed without physical access<br />
|<br />
|}<br />
<br />
=== Considerations ===<br />
<br />
* [https://esphome.io/# ESPHome] with e.g. e-paper hat or servo.<br />
<br />
=== Status ===<br />
{| class="wikitable"<br />
|+<br />
!<br />
!<br />
|-<br />
|Dual R3 #1, #2, #3 (w/ lead)<br />
|Tasmota flashed through wired interface. Shutter1-3<br />
|-<br />
|Shelly1 #1<br />
|Built into kitchen light switch. Original Shelly fw.<br />
|-<br />
|Shelly1 #2<br />
|issues with terminal screw twisted.<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3948Notes on sonoff, shelly, tasmota2021-08-02T19:30:48Z<p>Danny: </p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|<br />
* [https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
* [https://github.com/njh/sonoff-ota-flash-cli Bash script] for fashing Sonoff, including Mini<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
* [https://templates.blakadder.com/sonoff_DUALR3.html templates and flashing instructions]<br />
* Configure [https://tasmota.github.io/docs/Blinds-and-Shutters/ as shutter]<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
* [https://github.com/yaourdt/mgos-to-tasmota OTA] flashing<br />
|<br />
|}<br />
Device status:<br />
{| class="wikitable"<br />
|+<br />
!<br />
!<br />
|-<br />
|Dual R3 #1 (w/ lead)<br />
|Reset 5s, then Reset 5s again shows access point "ITEAD-<hex>"<br />
connect to 192.168.1.1 gives json struct with member "data"<br />
<br />
Try with laptop next.<br />
|-<br />
|Shelly1 #1<br />
|Built into kitchen light switch. Original Shelly fw.<br />
|-<br />
|Shelly1 #2<br />
|issues with terminal screw twisted.<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3947Notes on sonoff, shelly, tasmota2021-08-02T18:49:36Z<p>Danny: </p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|[https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
* [https://templates.blakadder.com/sonoff_DUALR3.html templates and flashing instructions]<br />
* Configure [https://tasmota.github.io/docs/Blinds-and-Shutters/ as shutter]<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
* [https://github.com/yaourdt/mgos-to-tasmota OTA] flashing<br />
|<br />
|}<br />
Device status:<br />
{| class="wikitable"<br />
|+<br />
!<br />
!<br />
|-<br />
|Dual R3 #1 (w/ lead)<br />
|Reset 5s, then Reset 5s again shows access point "ITEAD-<hex>"<br />
connect to 192.168.1.1 gives json struct with member "data"<br />
<br />
Try with laptop next.<br />
|-<br />
|Shelly1 #1<br />
|Built into kitchen light switch. Original Shelly fw.<br />
|-<br />
|Shelly1 #2<br />
|issues with terminal screw twisted.<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3946Notes on sonoff, shelly, tasmota2021-08-02T16:45:26Z<p>Danny: </p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|[https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
* [https://templates.blakadder.com/sonoff_DUALR3.html templates and flashing instructions]<br />
* Configure [https://tasmota.github.io/docs/Blinds-and-Shutters/ as shutter]<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
|<br />
|}<br />
Device status:<br />
{| class="wikitable"<br />
|+<br />
!<br />
!<br />
|-<br />
|Dual R3 #1 (w/ lead)<br />
|Reset 5s, then Reset 5s again shows access point "ITEAD-<hex>"<br />
connect to 192.168.1.1 gives json struct with member "data"<br />
<br />
Try with laptop next.<br />
|-<br />
|Shelly1 #1<br />
|Built into kitchen light switch. Original Shelly fw.<br />
|-<br />
|Shelly1 #2<br />
|issues with terminal screw twisted.<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3945Notes on sonoff, shelly, tasmota2021-07-31T22:44:39Z<p>Danny: </p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|[https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
* [https://templates.blakadder.com/sonoff_DUALR3.html templates and flashing instructions]<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
|<br />
|}<br />
Device status:<br />
{| class="wikitable"<br />
|+<br />
!<br />
!<br />
|-<br />
|Dual R3 #1 (w/ lead)<br />
|Reset 5s, then Reset 5s again shows access point "ITEAD-<hex>"<br />
connect to 192.168.1.1 gives json struct with member "data"<br />
<br />
Try with laptop next.<br />
|-<br />
|Shelly1 #1<br />
|Built into kitchen light switch. Original Shelly fw.<br />
|-<br />
|Shelly1 #2<br />
|issues with terminal screw twisted.<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3944Notes on sonoff, shelly, tasmota2021-06-14T22:26:38Z<p>Danny: </p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|[https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
|<br />
|}<br />
Device status:<br />
{| class="wikitable"<br />
|+<br />
!<br />
!<br />
|-<br />
|Dual R3 #1 (w/ lead)<br />
|Reset 5s, then Reset 5s again shows access point "ITEAD-<hex>"<br />
connect to 192.168.1.1 gives json struct with member "data"<br />
<br />
Try with laptop next.<br />
|-<br />
|Shelly1 #1<br />
|Built into kitchen light switch. Original Shelly fw.<br />
|-<br />
|Shelly1 #2<br />
|issues with terminal screw twisted.<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=Notes_on_sonoff,_shelly,_tasmota&diff=3943Notes on sonoff, shelly, tasmota2021-06-14T22:02:50Z<p>Danny: Created page with "{| class="wikitable" |+ !Device !Tasmota page !Flashing !Notes |- |Sonoff Mini R2 | |[https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch fla..."</p>
<hr />
<div>{| class="wikitable"<br />
|+<br />
!Device<br />
!Tasmota page<br />
!Flashing<br />
!Notes<br />
|-<br />
|Sonoff Mini R2<br />
|<br />
|[https://iot.formatx.net/sonoff-mini-r2-switch-flashing-tasmota/ Sonoff Mini R2 Switch flashing Tasmota]<br />
|<br />
|-<br />
|Sonoff Dual R3<br />
|<br />
|<br />
* [https://notenoughtech.com/home-automation/how-to-flash-tasmota-on-sonoff-dualr3/ link1] no OTA<br />
|<br />
|-<br />
|Shelly1 v3<br />
|<br />
|<br />
|<br />
|}</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3942WiFi telescope and camera control2021-02-04T11:01:52Z<p>Danny: /* Software */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem system overview.png|frameless|400x400px]]<br />
<br />
<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]] <br />
<br />
[[File:Schematic.jpg|441x441px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a [https://www.ebay.com/sch/i.html?_from=R40&_nkw=shutter+cable++nikon+d90&_sacat=0&_sop=15 shutter release cable on ebay] (shop around, it may be cheaper on other sites) and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem_in_enclosure.png|alt=|334x334px]] [[File:Partem_enclosure.png|alt=|307x307px]] <br />
<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and for most, sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a [https://github.com/DannyHavenith/Partem/blob/master/analysis/emulator.py python script] was written that emulates a simplified version of the telescope motor-controller. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.<br />
<br />
The direct app-to-python script mode was useful to analyse how the Synscan app interacts with the controller and to determine the underdocumented features of the protocol (e.g. the app uses direct "AT+..." commands to configure the telescope's Wifi settings)<br />
<br />
The app-to-controller-to-python script is a useful debug tool to see if the controller was correctly sending (or intercepting) messages from the app.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3941WiFi telescope and camera control2021-02-04T10:57:18Z<p>Danny: clarified the description of the Python emulator.</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem system overview.png|frameless|400x400px]]<br />
<br />
<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]] <br />
<br />
[[File:Schematic.jpg|441x441px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a [https://www.ebay.com/sch/i.html?_from=R40&_nkw=shutter+cable++nikon+d90&_sacat=0&_sop=15 shutter release cable on ebay] (shop around, it may be cheaper on other sites) and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem_in_enclosure.png|alt=|334x334px]] [[File:Partem_enclosure.png|alt=|307x307px]] <br />
<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and for most, sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a [https://github.com/DannyHavenith/Partem/blob/master/analysis/emulator.py python script] was written that emulates a simplified version of the telescope motor-controller. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.</div>Dannyhttps://rurandom.org/justintime/index.php?title=Driving_a_large_WS2811_LED_string_with_an_ATtiny13_and_nothing_else&diff=3940Driving a large WS2811 LED string with an ATtiny13 and nothing else2020-11-30T01:54:28Z<p>Danny: /* Application code */</p>
<hr />
<div>After creating code to [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|drive a WS2811/WS2812 LED string with an 8Mhz AVR]], some of the comments on that page triggered me to create a version of that code for AVRs that run at 9.6Mhz. In itself this was a lot easier, since these MCUs have more clock cycles per bit available than their 8 Mhz counterparts. However, when talking about 9.6 Mhz AVRs, we're actually talking about the ATtiny13. This MCU is fast, small and dirt-cheap, but is also limited in its resources: 64 bytes of RAM and 1024 bytes (= 512 instructions) flash memory.<br />
<br />
Our WS2811 driver, like all others that I've seen, is "memory mapped", which means that for every LED in an LED string the driver requires 3 bytes in memory and every such triplet directly maps onto one of the LEDs in the string. For a 64-byte MCU this means there is a theoretical limit of 21 LEDs in a string. In practice this is even less, because a typical program will use some stack space. I found that a simple color cycle demo could drive at most 13 LEDs. At the same time, most of the demos that I created only light up a few LEDs of the string, so the actual information content is much less than the n-times-3 for n LEDs. Wouldn't it be nice if we could drive such a sparsely lit string with only the bytes we need to describe the LEDs that are actually lit and maybe some bytes describing where these LEDs are?<br />
<br />
It turns out that not only is this possible, the resulting driver code is considerably smaller than our original 9.6 Mhz driver code as well! As a bonus, trying to fit an application in 500 instructions had a definite feel of historical re-enactment...<br />
<br />
The source code is now part of the regular WS2811 driver on [https://github.com/DannyHavenith/ws2811 GitHub]. Look for the file ''ws2811_controller_low_ram.cpp'' for demonstration code.<br />
<br />
{|<br />
|{{#ev:youtube|jAm7nVRvY_I|300|right|Driving 60 leds from a 64 byte RAM ATtiny13}}<br />
|{{#ev:youtube|mItPxAtkuVI|300|right|Flares demo}}<br />
|}<br />
{{StopImagesFlow}}<br />
==Sparse data representation==<br />
The new driver reads an array of bytes and sends out a ws2811 serial signal, just like the old one did. However, where the previous driver just read a sequence of green, red, blue-values from memory, the new one expects a sequence of bytes that describe blocks of consecutive LEDs, with for each block:<br />
<br />
# a byte containing the count of unlit LEDs preceding the block (the "Jump")<br />
# a byte containing the count of lit LEDs in the block (the "Count")<br />
# for each LED in the block a G, R and B value (three bytes per LED)<br />
<br />
Data is terminated by either a zero Jump value or a zero Count value, except for the first Jump, which can be zero if the first LED in the string should be lit.<br />
<br />
For example, suppose we want to create the following 20-LED string, where the leftmost LED is the first one:<br />
<br />
{| class="wikitable" border="1"<br />
! colspan="5"| 5 unlit<br />
! colspan="2"| 2 lit<br />
! colspan="8" | 8 unlit<br />
! 1 lit<br />
! colspan="4" | 4 unlit<br />
<br />
|-<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:blue;color:white;" | blue<br />
| style="background-color:red;color:black;" | red<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:yellow;color:black;" | yellow<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
| style="background-color:black;color:white;" | black<br />
|}<br />
<br />
We can represent this with the following buffer contents:<br />
<br />
{| class="wikitable"<br />
! Jump <br />
! Count <br />
! colspan = "3"|LED (GRB)<br />
! colspan = "3"|LED (GRB)<br />
! Jump <br />
! Count <br />
! colspan = "3"|LED (GRB)<br />
! Jump<br />
! terminate<br />
|-<br />
| 5 || 2 <br />
|style="background-color:blue;color:white;" | 0 <br />
|style="background-color:blue;color:white;" | 0 <br />
|style="background-color:blue;color:white;" | 255 <br />
|style="background-color:red;color:black;" | 0 <br />
|style="background-color:red;color:black;" | 255 <br />
|style="background-color:red;color:black;" | 0 <br />
| 8 || 1 <br />
| style="background-color:yellow;color:black;" | 255 <br />
| style="background-color:yellow;color:black;" | 255 <br />
| style="background-color:yellow;color:black;" | 0 <br />
| 4 || 0<br />
|}<br />
<br />
The memory mapped representation would require 60 bytes, the sparse representation takes only 15 bytes.<br />
<br />
==Driver code==<br />
First of all the code is split in two parts: sending zeros and sending data. Secondly, with 12 clock cycles per bit there is enough time to create a one-loop-per-bit driver. Only the last two bits are unrolled into a two-bit loop. The image below shows the assembly code with the generated waveform to the left. Also on the left is the phase (00-0b for the first bits and 10-1b for the last bit) of each instruction.<br />
<br />
[[File:Ws2811 96 assembly.png|link=https://github.com/DannyHavenith/ws2811/blob/master/design/ws2811@9.6Mhz.ods?raw=true]]<br />
<br />
The code that emits zero-bits starts at Z00 (Z for zero, 00 for phase 00). The top half of the code is used to emit the first 23-bits of a 24-bit zero sequence. If we find that we're sending the last zero-bit, the code falls through to the second half where the number of data bytes is determined and where the code jumps to s00 where the data waveform is generated.<br />
<br />
The code that starts at s00 follows the same structure: the first 7 bits are send in a small loop, phases 00 to 0b. If we're sending the final bit, the code falls through to the second half (phases 10-1b) where we read the number of zeros to transmit and if that is non-zero we'll fall through to z00 again.<br />
<br />
==Application code==<br />
While the sparse representation makes it easy for the driver to send the complete waveform for an LED string in a timed fashion, things have become much harder for most applications. Previously, when an application needed to set an LED at a given position to a given color that would look like this:<br />
<syntaxhighlight lang='cpp'><br />
rgb leds[60]; // declare a string of 60 LEDs as a simple array of RGB-values.<br />
// turn the 10th LED purple<br />
leds[9] = rgb( 255, 0, 255);<br />
</syntaxhighlight><br />
Problem is, with the sparse representation we don't know where in the buffer we need to put the data for a pixel at a given position, this depends on the other pixels that are described in the buffer. So either we have to rewrite all applications/demos to create a sparse buffer in one go, or we create a function that can find the n-th pixel in the buffer and that performs all manipulations necessary to make sure that there is space for that pixel inside the buffer.<br />
<br />
I chose the latter option, which comes at a cost (code space), but which allows the application code to be almost exactly the same as the memory mapped version. The extra code space is considerate however. The [[Get led code|implementation of the function]] that finds or creates the space for an LED takes more instructions than the driver itself. The new source code becomes:<br />
<br />
<syntaxhighlight lang='cpp'><br />
sparse_leds<38, 60> leds; // declare a sparse buffer of 38 bytes for a string of 60 LEDs<br />
// turn the 10th LED purple<br />
get( leds, 9) = rgb( 255, 0, 255);<br />
</syntaxhighlight><br />
<br />
I shortly tested whether I could turn this in an '''operator[]''' to make the syntax exactly the same as the array variant. Although the operator works and does not incur any overhead, I decided against it, because using a free function reminds the programmer (me) that a non-trivial calculation takes place. The compiler doesn't seem to memoize the call to the operator or get()-function either, so it is wise to call this function only when needed and to hold the results when it is used more than once. The library also contains an overload of the get()-function for arrays of rgb-values. This makes it easy to create programs that work for both types of LED string buffers:<br />
<br />
<syntaxhighlight lang='cpp'><br />
rgb leds[60]; // declare a string of 60 LEDs as a simple array of RGB-values.<br />
// turn the 10th LED purple<br />
get( leds, 9) = rgb( 255, 0, 255);<br />
</syntaxhighlight><br />
<br />
==Downloading the demo code==<br />
The sparse and 9.6Mhz code is now integrated in the regular [https://github.com/DannyHavenith/ws2811 Github repository]. The attiny13 demonstration code starts in [https://github.com/DannyHavenith/ws2811/blob/master/demo/ws2811_controller_low_ram.cpp ws2811_controller_low_ram.cpp]. Examples of demo code that runs on both the sparse buffers as on regular memory-mapped buffers are in [https://github.com/DannyHavenith/ws2811/blob/master/demo/flares.hpp flares.hpp] and in [https://github.com/DannyHavenith/ws2811/blob/master/demo/chasers.hpp chasers.hpp].<br />
<br />
==Comments? Questions?==<br />
{{ShowComments|show=True}}<br />
<br />
[[Category:AVR]][[Category:WS2811]]</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Telescope_and_camera.png&diff=3939File:Telescope and camera.png2020-11-19T22:48:24Z<p>Danny: Danny uploaded a new version of File:Telescope and camera.png</p>
<hr />
<div>An image of my Skywatcher 150mm reflector telescope with camera attached.</div>Dannyhttps://rurandom.org/justintime/index.php?title=Main_Page&diff=3938Main Page2020-11-19T21:17:39Z<p>Danny: /* Featured */</p>
<hr />
<div>=Just In Time Project Pages=<br />
These pages contain descriptions of our electronics projects, mainly involving [http://www.atmel.com/products/avr/ AVR] microcontrollers.<br />
__TOC__<br />
==Featured==<br />
{| class="wikitable" border="1"<br />
|-<br />
|style="width:64px;"|[[File:Ws2811 thumbnail.jpg|upright=1.0|link=Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| '''WS2811 LED strips & 8Mhz AVR'''<br />
Want to know how to drive a WS2811 led string from an 8 Mhz AVR? [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|This page]] has the code and explains it. Works for Arduino too...<br />
|-<br />
|[[File:Hamsterwheel thumbnail.png|64px|link=Internet of Hamsters]]<br />
|'''Internet of Hamsters'''<br />
It's [[Internet of Hamsters|hamsters]]. It's internet. What more could you possible want?<br />
|-<br />
|[[File:Telescope thumbnail.png|64px|link=WiFi telescope and camera control]]<br />
|'''Telescope and camera control'''<br />
[[WiFi telescope and camera control|WiFi-to-serial bridge]] allowing existing apps to talk to a telescope, but also control an attached camera<br />
|-<br />
| [[File:Transceiver433 cropped.jpg|64px|link=Cheapest ever 433 Mhz transceiver for PCs]]<br />
| '''USB 433Mhz transceiver for $3'''<br />
Cheap 433Mhz receivers and transmitters are ideal to communicate with your microcontroller, but can also be used to control inexpensive RF-controlled switches. If you've got $3, an ebay account and a soldering iron, you can now [[Cheapest ever 433 Mhz transceiver for PCs|control your light switches through a USB port]].<br />
|-<br />
| [[File:FD8 thumb.jpg|64px|link=Digital FD-8 pedal]]<br />
| '''Digital FD-8 repair'''<br />
Roland FD-8 hi-hat pedals have a tendency to become unresponsive over time. Instead of trying to repair the internal film resistor, why not completely [[Digital FD-8 pedal|replace its guts with a small microcontroller]] for accurate control without wear and tear? If you think a microcontroller is overkill, we also have [[Roland FD-8 Issues: Hall Sensor Modification|an analog electronics version]].<br />
|-<br />
| [[File:Straddling header thumbnail.jpg|64px|link=Evolution of breadboard programming headers]]<br />
| '''Breadboard AVR Programming Headers'''<br />
To celebrate the release of Vinnies [[Vinnies Definite Straddling Header|student-proof, straddling programming header]], we've finally gotten around to documenting the [[Evolution of breadboard programming headers|programming headers]] we use for AVR breadboard programming!<br />
|}<br />
<br />
==Projects==<br />
Here are some finished, or work in progress activities:<br />
{| class="wikitable sortable mw-collapsible" border="1"<br />
|-<br />
! Project<br />
! Page status<br />
! Project status<br />
|-<br />
| [[Identifying Christmas Lights]] (ongoing project log)<br />
|started<br />
|ongoing<br />
|-<br />
| [[Fast, arduino compatible digital pin functions]], digitalWrite() in 2 clock ticks<br />
| started<br />
| finished<br />
|-<br />
| [[Sending location information from an Android phone to a Nikon camera]]<br />
| started<br />
| halted<br />
|-<br />
| [[WS2811 "Water torture"]]<br />
| started<br />
| finished<br />
|-<br />
| [[Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| finished<br />
| ongoing<br />
|-<br />
| [[4x4x4 Led Cube - AVR doing Bit Angle Modulation / Single PCB base]]<br />
| started<br />
| finished<br />
|-<br />
| [[Cheapest ever 433 Mhz transceiver for PCs]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Roland FD-8 Issues: Hall Sensor Modification]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Antique Clock Start Stop Automation]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Knight Rider]] walking led experiments<br> demonstrating pwm, either through SX [[Virtual Peripherals]] or inline and [[How to drive many leds with a few io-pins]].<br />
| basic<br />
| finished<br />
|-<br />
|[[Wireless LCD display]]<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving a shift register led display driver]].<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving 4 seven segment led displays]]<br />
| not started<br />
| finished<br />
|-<br />
|[['Very Limited Space' Midi Sustain Pedal]].<br />
| not started<br />
| finished<br />
|-<br />
|[[Fake Cricket]].<br />
| complete<br />
| finished<br />
|-<br />
|[[Reading Rotary Encoders]]<br />
| complete<br />
| finished (component)<br />
|-<br />
|[[Oven temperature controller]]<br />
| in progress<br />
| halted<br />
|-<br />
|[[RGB Light Show (Wired/Wireless)]]<br />
| started<br />
| finished<br />
|-<br />
|Digital Analogue Clock with Traffic Light alarm<br />
| not started<br />
| finished<br />
|-<br />
|[[Diffusing Leds the Fast Way]]<br />
| complete<br />
| finished<br />
|}<br />
<br />
Some older software projects: <br />
*An [[eclipse plugin for SX assembly language]].<br />
*[[Sxgo]], a fast, portable SX28 emulator.<br />
<br />
==Programming AVRs==<br />
You might want to know how to [[running avrdude from eclipse under linux|run avrdude from eclipse under linux]].<br />
<br />
Atmel has released a 4K version of the well-known Attiny2313, called the Attiny4313. It is fully (pin) compatible, with the only difference that it has double memory. The Attiny4313 is not yet recognized by Avrdude, so we have modified the Avrdude config file to be able to program it. [[ATtiny4313 AVRDude configuration|This link]] contains the Attiny4313 section that should be added to your config.<br />
<br />
==Our set up==<br />
Nowadays, we prefer to do our stuff in SMT because it avoids the bore of drilling holes (yes, pun intended). And you can make use of cheap SMT resistor and capacitor assortments so you'll always have the right values available. Working in SMT requires making PCBs. We use the toner transfer method. One tip: the ironing sticks much better if the paper is wet. And one other tip: etching in [http://www.instructables.com/id/Stop-using-Ferric-Chloride-etchant!--A-better-etc/ cupric chloride] works very well and you never run out of etchant!<br />
<br />
{|<br />
|-<br />
|[[File:CuCl.jpg|thumb]]<br />
|[[File:smt resistors.jpg|thumb]]<br />
|[[File:pcb printed.jpg|thumb]]<br />
|}<br />
<br />
==ToDo List==<br />
Here are some projects on our to do list:<br />
* <s>CC2500 Wireless System</s>, on hold while we're working on the <br />
* Nordic NRF24L01+ wireless system (first library now part of [https://github.com/DannyHavenith/avr_utilities avr_utilities])<br />
* Update our [[RGB Light Show (Wired/Wireless)|RGB spotlights]] to use Bit Angle Modulation<br />
* AVR DAC Audio playback<br />
* Midi Chord generator<br />
* Solarpower Chicken Lighting System<br />
* PIC-based MidiFilePlayer<br />
* Drumcomputer<br />
* DCC Train control system<br />
* simple GPS logger based on rs232 receiver<br />
* sunrise alarm clock<br />
<br />
Items that were on this list, but are finished now (without write-up)<br />
* 100Mhz SX based Frequency Counter (done)<br />
* AVR Bootloader System (done)</div>Dannyhttps://rurandom.org/justintime/index.php?title=Main_Page&diff=3937Main Page2020-11-19T21:17:01Z<p>Danny: /* Featured */</p>
<hr />
<div>=Just In Time Project Pages=<br />
These pages contain descriptions of our electronics projects, mainly involving [http://www.atmel.com/products/avr/ AVR] microcontrollers.<br />
__TOC__<br />
==Featured==<br />
{| class="wikitable" border="1"<br />
|-<br />
|style="width:64px;"|[[File:Ws2811 thumbnail.jpg|upright=1.0|link=Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| '''WS2811 LED strips & 8Mhz AVR'''<br />
Want to know how to drive a WS2811 led string from an 8 Mhz AVR? [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|This page]] has the code and explains it. Works for Arduino too...<br />
|-<br />
|[[File:Hamsterwheel thumbnail.png|64px|link=Internet of Hamsters]]<br />
|'''Internet of Hamsters'''<br />
It's [[Internet of Hamsters|hamsters]]. It's internet. What more could you possible want?<br />
|-<br />
| [[File:Transceiver433 cropped.jpg|64px|link=Cheapest ever 433 Mhz transceiver for PCs]]<br />
| '''USB 433Mhz transceiver for $3'''<br />
Cheap 433Mhz receivers and transmitters are ideal to communicate with your microcontroller, but can also be used to control inexpensive RF-controlled switches. If you've got $3, an ebay account and a soldering iron, you can now [[Cheapest ever 433 Mhz transceiver for PCs|control your light switches through a USB port]].<br />
|-<br />
|[[File:Telescope thumbnail.png|64px|link=WiFi telescope and camera control]]<br />
|'''Telescope and camera control'''<br />
[[WiFi telescope and camera control|WiFi-to-serial bridge]] allowing existing apps to talk to a telescope, but also control an attached camera<br />
|-<br />
| [[File:FD8 thumb.jpg|64px|link=Digital FD-8 pedal]]<br />
| '''Digital FD-8 repair'''<br />
Roland FD-8 hi-hat pedals have a tendency to become unresponsive over time. Instead of trying to repair the internal film resistor, why not completely [[Digital FD-8 pedal|replace its guts with a small microcontroller]] for accurate control without wear and tear? If you think a microcontroller is overkill, we also have [[Roland FD-8 Issues: Hall Sensor Modification|an analog electronics version]].<br />
|-<br />
| [[File:Straddling header thumbnail.jpg|64px|link=Evolution of breadboard programming headers]]<br />
| '''Breadboard AVR Programming Headers'''<br />
To celebrate the release of Vinnies [[Vinnies Definite Straddling Header|student-proof, straddling programming header]], we've finally gotten around to documenting the [[Evolution of breadboard programming headers|programming headers]] we use for AVR breadboard programming!<br />
|}<br />
<br />
==Projects==<br />
Here are some finished, or work in progress activities:<br />
{| class="wikitable sortable mw-collapsible" border="1"<br />
|-<br />
! Project<br />
! Page status<br />
! Project status<br />
|-<br />
| [[Identifying Christmas Lights]] (ongoing project log)<br />
|started<br />
|ongoing<br />
|-<br />
| [[Fast, arduino compatible digital pin functions]], digitalWrite() in 2 clock ticks<br />
| started<br />
| finished<br />
|-<br />
| [[Sending location information from an Android phone to a Nikon camera]]<br />
| started<br />
| halted<br />
|-<br />
| [[WS2811 "Water torture"]]<br />
| started<br />
| finished<br />
|-<br />
| [[Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| finished<br />
| ongoing<br />
|-<br />
| [[4x4x4 Led Cube - AVR doing Bit Angle Modulation / Single PCB base]]<br />
| started<br />
| finished<br />
|-<br />
| [[Cheapest ever 433 Mhz transceiver for PCs]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Roland FD-8 Issues: Hall Sensor Modification]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Antique Clock Start Stop Automation]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Knight Rider]] walking led experiments<br> demonstrating pwm, either through SX [[Virtual Peripherals]] or inline and [[How to drive many leds with a few io-pins]].<br />
| basic<br />
| finished<br />
|-<br />
|[[Wireless LCD display]]<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving a shift register led display driver]].<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving 4 seven segment led displays]]<br />
| not started<br />
| finished<br />
|-<br />
|[['Very Limited Space' Midi Sustain Pedal]].<br />
| not started<br />
| finished<br />
|-<br />
|[[Fake Cricket]].<br />
| complete<br />
| finished<br />
|-<br />
|[[Reading Rotary Encoders]]<br />
| complete<br />
| finished (component)<br />
|-<br />
|[[Oven temperature controller]]<br />
| in progress<br />
| halted<br />
|-<br />
|[[RGB Light Show (Wired/Wireless)]]<br />
| started<br />
| finished<br />
|-<br />
|Digital Analogue Clock with Traffic Light alarm<br />
| not started<br />
| finished<br />
|-<br />
|[[Diffusing Leds the Fast Way]]<br />
| complete<br />
| finished<br />
|}<br />
<br />
Some older software projects: <br />
*An [[eclipse plugin for SX assembly language]].<br />
*[[Sxgo]], a fast, portable SX28 emulator.<br />
<br />
==Programming AVRs==<br />
You might want to know how to [[running avrdude from eclipse under linux|run avrdude from eclipse under linux]].<br />
<br />
Atmel has released a 4K version of the well-known Attiny2313, called the Attiny4313. It is fully (pin) compatible, with the only difference that it has double memory. The Attiny4313 is not yet recognized by Avrdude, so we have modified the Avrdude config file to be able to program it. [[ATtiny4313 AVRDude configuration|This link]] contains the Attiny4313 section that should be added to your config.<br />
<br />
==Our set up==<br />
Nowadays, we prefer to do our stuff in SMT because it avoids the bore of drilling holes (yes, pun intended). And you can make use of cheap SMT resistor and capacitor assortments so you'll always have the right values available. Working in SMT requires making PCBs. We use the toner transfer method. One tip: the ironing sticks much better if the paper is wet. And one other tip: etching in [http://www.instructables.com/id/Stop-using-Ferric-Chloride-etchant!--A-better-etc/ cupric chloride] works very well and you never run out of etchant!<br />
<br />
{|<br />
|-<br />
|[[File:CuCl.jpg|thumb]]<br />
|[[File:smt resistors.jpg|thumb]]<br />
|[[File:pcb printed.jpg|thumb]]<br />
|}<br />
<br />
==ToDo List==<br />
Here are some projects on our to do list:<br />
* <s>CC2500 Wireless System</s>, on hold while we're working on the <br />
* Nordic NRF24L01+ wireless system (first library now part of [https://github.com/DannyHavenith/avr_utilities avr_utilities])<br />
* Update our [[RGB Light Show (Wired/Wireless)|RGB spotlights]] to use Bit Angle Modulation<br />
* AVR DAC Audio playback<br />
* Midi Chord generator<br />
* Solarpower Chicken Lighting System<br />
* PIC-based MidiFilePlayer<br />
* Drumcomputer<br />
* DCC Train control system<br />
* simple GPS logger based on rs232 receiver<br />
* sunrise alarm clock<br />
<br />
Items that were on this list, but are finished now (without write-up)<br />
* 100Mhz SX based Frequency Counter (done)<br />
* AVR Bootloader System (done)</div>Dannyhttps://rurandom.org/justintime/index.php?title=Main_Page&diff=3936Main Page2020-11-19T21:13:58Z<p>Danny: /* Featured */</p>
<hr />
<div>=Just In Time Project Pages=<br />
These pages contain descriptions of our electronics projects, mainly involving [http://www.atmel.com/products/avr/ AVR] microcontrollers.<br />
__TOC__<br />
==Featured==<br />
{| class="wikitable" border="1"<br />
|-<br />
|style="width:64px;"|[[File:Ws2811 thumbnail.jpg|upright=1.0|link=Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| '''WS2811 LED strips & 8Mhz AVR'''<br />
Want to know how to drive a WS2811 led string from an 8 Mhz AVR? [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|This page]] has the code and explains it. Works for Arduino too...<br />
|-<br />
| [[File:Transceiver433 cropped.jpg|64px|link=Cheapest ever 433 Mhz transceiver for PCs]]<br />
| '''USB 433Mhz transceiver for $3'''<br />
Cheap 433Mhz receivers and transmitters are ideal to communicate with your microcontroller, but can also be used to control inexpensive RF-controlled switches. If you've got $3, an ebay account and a soldering iron, you can now [[Cheapest ever 433 Mhz transceiver for PCs|control your light switches through a USB port]].<br />
|-<br />
| [[File:FD8 thumb.jpg|64px|link=Digital FD-8 pedal]]<br />
| '''Digital FD-8 repair'''<br />
Roland FD-8 hi-hat pedals have a tendency to become unresponsive over time. Instead of trying to repair the internal film resistor, why not completely [[Digital FD-8 pedal|replace its guts with a small microcontroller]] for accurate control without wear and tear? If you think a microcontroller is overkill, we also have [[Roland FD-8 Issues: Hall Sensor Modification|an analog electronics version]].<br />
|-<br />
| [[File:Straddling header thumbnail.jpg|64px|link=Evolution of breadboard programming headers]]<br />
| '''Breadboard AVR Programming Headers'''<br />
To celebrate the release of Vinnies [[Vinnies Definite Straddling Header|student-proof, straddling programming header]], we've finally gotten around to documenting the [[Evolution of breadboard programming headers|programming headers]] we use for AVR breadboard programming!<br />
|-<br />
| [[File:Hamsterwheel thumbnail.png|64px|link=Internet of Hamsters]]<br />
| '''Internet of Hamsters'''<br />
It's [[Internet of Hamsters|hamsters]]. It's internet. What more could you possible want?<br />
|-<br />
| [[File:Telescope thumbnail.png|64px|link=WiFi telescope and camera control]]<br />
| '''Telescope and camera control'''<br />
[[WiFi telescope and camera control|WiFi-to-serial bridge]] allowing existing apps to talk to a telescope, but also control an attached camera<br />
|}<br />
<br />
==Projects==<br />
Here are some finished, or work in progress activities:<br />
{| class="wikitable sortable mw-collapsible" border="1"<br />
|-<br />
! Project<br />
! Page status<br />
! Project status<br />
|-<br />
| [[Identifying Christmas Lights]] (ongoing project log)<br />
|started<br />
|ongoing<br />
|-<br />
| [[Fast, arduino compatible digital pin functions]], digitalWrite() in 2 clock ticks<br />
| started<br />
| finished<br />
|-<br />
| [[Sending location information from an Android phone to a Nikon camera]]<br />
| started<br />
| halted<br />
|-<br />
| [[WS2811 "Water torture"]]<br />
| started<br />
| finished<br />
|-<br />
| [[Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| finished<br />
| ongoing<br />
|-<br />
| [[4x4x4 Led Cube - AVR doing Bit Angle Modulation / Single PCB base]]<br />
| started<br />
| finished<br />
|-<br />
| [[Cheapest ever 433 Mhz transceiver for PCs]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Roland FD-8 Issues: Hall Sensor Modification]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Antique Clock Start Stop Automation]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Knight Rider]] walking led experiments<br> demonstrating pwm, either through SX [[Virtual Peripherals]] or inline and [[How to drive many leds with a few io-pins]].<br />
| basic<br />
| finished<br />
|-<br />
|[[Wireless LCD display]]<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving a shift register led display driver]].<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving 4 seven segment led displays]]<br />
| not started<br />
| finished<br />
|-<br />
|[['Very Limited Space' Midi Sustain Pedal]].<br />
| not started<br />
| finished<br />
|-<br />
|[[Fake Cricket]].<br />
| complete<br />
| finished<br />
|-<br />
|[[Reading Rotary Encoders]]<br />
| complete<br />
| finished (component)<br />
|-<br />
|[[Oven temperature controller]]<br />
| in progress<br />
| halted<br />
|-<br />
|[[RGB Light Show (Wired/Wireless)]]<br />
| started<br />
| finished<br />
|-<br />
|Digital Analogue Clock with Traffic Light alarm<br />
| not started<br />
| finished<br />
|-<br />
|[[Diffusing Leds the Fast Way]]<br />
| complete<br />
| finished<br />
|}<br />
<br />
Some older software projects: <br />
*An [[eclipse plugin for SX assembly language]].<br />
*[[Sxgo]], a fast, portable SX28 emulator.<br />
<br />
==Programming AVRs==<br />
You might want to know how to [[running avrdude from eclipse under linux|run avrdude from eclipse under linux]].<br />
<br />
Atmel has released a 4K version of the well-known Attiny2313, called the Attiny4313. It is fully (pin) compatible, with the only difference that it has double memory. The Attiny4313 is not yet recognized by Avrdude, so we have modified the Avrdude config file to be able to program it. [[ATtiny4313 AVRDude configuration|This link]] contains the Attiny4313 section that should be added to your config.<br />
<br />
==Our set up==<br />
Nowadays, we prefer to do our stuff in SMT because it avoids the bore of drilling holes (yes, pun intended). And you can make use of cheap SMT resistor and capacitor assortments so you'll always have the right values available. Working in SMT requires making PCBs. We use the toner transfer method. One tip: the ironing sticks much better if the paper is wet. And one other tip: etching in [http://www.instructables.com/id/Stop-using-Ferric-Chloride-etchant!--A-better-etc/ cupric chloride] works very well and you never run out of etchant!<br />
<br />
{|<br />
|-<br />
|[[File:CuCl.jpg|thumb]]<br />
|[[File:smt resistors.jpg|thumb]]<br />
|[[File:pcb printed.jpg|thumb]]<br />
|}<br />
<br />
==ToDo List==<br />
Here are some projects on our to do list:<br />
* <s>CC2500 Wireless System</s>, on hold while we're working on the <br />
* Nordic NRF24L01+ wireless system (first library now part of [https://github.com/DannyHavenith/avr_utilities avr_utilities])<br />
* Update our [[RGB Light Show (Wired/Wireless)|RGB spotlights]] to use Bit Angle Modulation<br />
* AVR DAC Audio playback<br />
* Midi Chord generator<br />
* Solarpower Chicken Lighting System<br />
* PIC-based MidiFilePlayer<br />
* Drumcomputer<br />
* DCC Train control system<br />
* simple GPS logger based on rs232 receiver<br />
* sunrise alarm clock<br />
<br />
Items that were on this list, but are finished now (without write-up)<br />
* 100Mhz SX based Frequency Counter (done)<br />
* AVR Bootloader System (done)</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Telescope_thumbnail.png&diff=3935File:Telescope thumbnail.png2020-11-19T21:10:52Z<p>Danny: </p>
<hr />
<div>thumbnail image showing a telescope</div>Dannyhttps://rurandom.org/justintime/index.php?title=Main_Page&diff=3934Main Page2020-11-19T21:09:23Z<p>Danny: /* Featured */</p>
<hr />
<div>=Just In Time Project Pages=<br />
These pages contain descriptions of our electronics projects, mainly involving [http://www.atmel.com/products/avr/ AVR] microcontrollers.<br />
__TOC__<br />
==Featured==<br />
{| class="wikitable" border="1"<br />
|-<br />
|style="width:64px;"|[[File:Ws2811 thumbnail.jpg|upright=1.0|link=Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| '''WS2811 LED strips & 8Mhz AVR'''<br />
Want to know how to drive a WS2811 led string from an 8 Mhz AVR? [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|This page]] has the code and explains it. Works for Arduino too...<br />
|-<br />
| [[File:Transceiver433 cropped.jpg|64px|link=Cheapest ever 433 Mhz transceiver for PCs]]<br />
| '''USB 433Mhz transceiver for $3'''<br />
Cheap 433Mhz receivers and transmitters are ideal to communicate with your microcontroller, but can also be used to control inexpensive RF-controlled switches. If you've got $3, an ebay account and a soldering iron, you can now [[Cheapest ever 433 Mhz transceiver for PCs|control your light switches through a USB port]].<br />
|-<br />
| [[File:FD8 thumb.jpg|64px|link=Digital FD-8 pedal]]<br />
| '''Digital FD-8 repair'''<br />
Roland FD-8 hi-hat pedals have a tendency to become unresponsive over time. Instead of trying to repair the internal film resistor, why not completely [[Digital FD-8 pedal|replace its guts with a small microcontroller]] for accurate control without wear and tear? If you think a microcontroller is overkill, we also have [[Roland FD-8 Issues: Hall Sensor Modification|an analog electronics version]].<br />
|-<br />
| [[File:Straddling header thumbnail.jpg|64px|link=Evolution of breadboard programming headers]]<br />
| '''Breadboard AVR Programming Headers'''<br />
To celebrate the release of Vinnies [[Vinnies Definite Straddling Header|student-proof, straddling programming header]], we've finally gotten around to documenting the [[Evolution of breadboard programming headers|programming headers]] we use for AVR breadboard programming!<br />
|-<br />
| [[File:Hamsterwheel thumbnail.png|64px|link=Internet of Hamsters]]<br />
| '''Internet of Hamsters'''<br />
It's [[Internet of Hamsters|hamsters]]. It's internet. What more could you possible want?<br />
|-<br />
|<br />
| '''Telescope and camera control'''<br />
[[WiFi telescope and camera control|WiFi-to-serial bridge]] allowing existing apps to talk to a telescope, but also control an attached camera<br />
|}<br />
<br />
==Projects==<br />
Here are some finished, or work in progress activities:<br />
{| class="wikitable sortable mw-collapsible" border="1"<br />
|-<br />
! Project<br />
! Page status<br />
! Project status<br />
|-<br />
| [[Identifying Christmas Lights]] (ongoing project log)<br />
|started<br />
|ongoing<br />
|-<br />
| [[Fast, arduino compatible digital pin functions]], digitalWrite() in 2 clock ticks<br />
| started<br />
| finished<br />
|-<br />
| [[Sending location information from an Android phone to a Nikon camera]]<br />
| started<br />
| halted<br />
|-<br />
| [[WS2811 "Water torture"]]<br />
| started<br />
| finished<br />
|-<br />
| [[Driving the WS2811 at 800 kHz with an 8 MHz AVR]]<br />
| finished<br />
| ongoing<br />
|-<br />
| [[4x4x4 Led Cube - AVR doing Bit Angle Modulation / Single PCB base]]<br />
| started<br />
| finished<br />
|-<br />
| [[Cheapest ever 433 Mhz transceiver for PCs]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Roland FD-8 Issues: Hall Sensor Modification]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Antique Clock Start Stop Automation]]<br />
| complete<br />
| finished<br />
|-<br />
|[[Knight Rider]] walking led experiments<br> demonstrating pwm, either through SX [[Virtual Peripherals]] or inline and [[How to drive many leds with a few io-pins]].<br />
| basic<br />
| finished<br />
|-<br />
|[[Wireless LCD display]]<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving a shift register led display driver]].<br />
| rudimentary<br />
| finished<br />
|-<br />
|[[Driving 4 seven segment led displays]]<br />
| not started<br />
| finished<br />
|-<br />
|[['Very Limited Space' Midi Sustain Pedal]].<br />
| not started<br />
| finished<br />
|-<br />
|[[Fake Cricket]].<br />
| complete<br />
| finished<br />
|-<br />
|[[Reading Rotary Encoders]]<br />
| complete<br />
| finished (component)<br />
|-<br />
|[[Oven temperature controller]]<br />
| in progress<br />
| halted<br />
|-<br />
|[[RGB Light Show (Wired/Wireless)]]<br />
| started<br />
| finished<br />
|-<br />
|Digital Analogue Clock with Traffic Light alarm<br />
| not started<br />
| finished<br />
|-<br />
|[[Diffusing Leds the Fast Way]]<br />
| complete<br />
| finished<br />
|}<br />
<br />
Some older software projects: <br />
*An [[eclipse plugin for SX assembly language]].<br />
*[[Sxgo]], a fast, portable SX28 emulator.<br />
<br />
==Programming AVRs==<br />
You might want to know how to [[running avrdude from eclipse under linux|run avrdude from eclipse under linux]].<br />
<br />
Atmel has released a 4K version of the well-known Attiny2313, called the Attiny4313. It is fully (pin) compatible, with the only difference that it has double memory. The Attiny4313 is not yet recognized by Avrdude, so we have modified the Avrdude config file to be able to program it. [[ATtiny4313 AVRDude configuration|This link]] contains the Attiny4313 section that should be added to your config.<br />
<br />
==Our set up==<br />
Nowadays, we prefer to do our stuff in SMT because it avoids the bore of drilling holes (yes, pun intended). And you can make use of cheap SMT resistor and capacitor assortments so you'll always have the right values available. Working in SMT requires making PCBs. We use the toner transfer method. One tip: the ironing sticks much better if the paper is wet. And one other tip: etching in [http://www.instructables.com/id/Stop-using-Ferric-Chloride-etchant!--A-better-etc/ cupric chloride] works very well and you never run out of etchant!<br />
<br />
{|<br />
|-<br />
|[[File:CuCl.jpg|thumb]]<br />
|[[File:smt resistors.jpg|thumb]]<br />
|[[File:pcb printed.jpg|thumb]]<br />
|}<br />
<br />
==ToDo List==<br />
Here are some projects on our to do list:<br />
* <s>CC2500 Wireless System</s>, on hold while we're working on the <br />
* Nordic NRF24L01+ wireless system (first library now part of [https://github.com/DannyHavenith/avr_utilities avr_utilities])<br />
* Update our [[RGB Light Show (Wired/Wireless)|RGB spotlights]] to use Bit Angle Modulation<br />
* AVR DAC Audio playback<br />
* Midi Chord generator<br />
* Solarpower Chicken Lighting System<br />
* PIC-based MidiFilePlayer<br />
* Drumcomputer<br />
* DCC Train control system<br />
* simple GPS logger based on rs232 receiver<br />
* sunrise alarm clock<br />
<br />
Items that were on this list, but are finished now (without write-up)<br />
* 100Mhz SX based Frequency Counter (done)<br />
* AVR Bootloader System (done)</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3933WiFi telescope and camera control2020-11-19T17:54:28Z<p>Danny: /* Software */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem system overview.png|frameless|400x400px]]<br />
<br />
<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]] <br />
<br />
[[File:Schematic.jpg|441x441px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a [https://www.ebay.com/sch/i.html?_from=R40&_nkw=shutter+cable++nikon+d90&_sacat=0&_sop=15 shutter release cable on ebay] (shop around, it may be cheaper on other sites) and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem_in_enclosure.png|alt=|334x334px]] [[File:Partem_enclosure.png|alt=|307x307px]] <br />
<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and for most, sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3932WiFi telescope and camera control2020-11-19T17:52:41Z<p>Danny: /* Hardware */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem system overview.png|frameless|400x400px]]<br />
<br />
<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]] <br />
<br />
[[File:Schematic.jpg|441x441px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a [https://www.ebay.com/sch/i.html?_from=R40&_nkw=shutter+cable++nikon+d90&_sacat=0&_sop=15 shutter release cable on ebay] (shop around, it may be cheaper on other sites) and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem_in_enclosure.png|alt=|334x334px]] [[File:Partem_enclosure.png|alt=|307x307px]] <br />
<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3931WiFi telescope and camera control2020-11-18T02:14:46Z<p>Danny: /* Hardware */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem system overview.png|frameless|400x400px]]<br />
<br />
<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]] <br />
<br />
[[File:Schematic.jpg|441x441px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a shutter release cable on ebay and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem_in_enclosure.png|alt=|334x334px]] [[File:Partem_enclosure.png|alt=|307x307px]] <br />
<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Schematic.jpg&diff=3930File:Schematic.jpg2020-11-18T02:12:24Z<p>Danny: </p>
<hr />
<div>Schematic drawing of the electronics</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3929WiFi telescope and camera control2020-11-17T22:23:34Z<p>Danny: /* System overview */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem system overview.png|frameless|400x400px]]<br />
<br />
<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a shutter release cable on ebay and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem in enclosure.png|left|frameless]] [[File:Partem enclosure.png|right|frameless]]<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_system_overview.png&diff=3928File:Partem system overview.png2020-11-17T22:23:06Z<p>Danny: </p>
<hr />
<div>illustration showing a cell phone signalling to the partem device, which is connected to a telescope mount and a camera.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3927WiFi telescope and camera control2020-11-17T22:15:48Z<p>Danny: /* System overview */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
[[File:Partem overview2.svg|frameless]]<br />
"Partem" is a device that will either connect to a WiFi network or act as a WiFi access point itself. The device will listen to a UDP port and forward incoming data to its serial port. The serial port is connected to the motor controller of a SkyWatcher telescope mount. This setup allows the SynScan Pro app to communicate with the mount. Whenever the SynScan Pro app sends SNAP port messages, these messages will be intercepted and used to control a camera connected to the device.<br />
<br />
== Hardware ==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I had one lying around, I used an old RJ-12 (telephone) socket for the connection to the camera. The enclosure was then designed to accommodate for that connector. Typically, you'd want a stereo mini jack connector for such cables, because that's how they are often sold.<br />
<br />
I instead bought a shutter release cable on ebay and soldered it to a telephone cable for additional length.<br />
<br />
[[File:Partem in enclosure.png|left|frameless]] [[File:Partem enclosure.png|right|frameless]]<br />
== Software ==<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].<br />
<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_enclosure.png&diff=3926File:Partem enclosure.png2020-11-17T22:11:36Z<p>Danny: </p>
<hr />
<div>Picture of device enclosure with attached cables.</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_in_enclosure.png&diff=3925File:Partem in enclosure.png2020-11-17T21:49:28Z<p>Danny: </p>
<hr />
<div>picture showing the electronics in an enclosure with the lid off.</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_overview2.svg&diff=3924File:Partem overview2.svg2020-11-17T21:37:08Z<p>Danny: </p>
<hr />
<div>System overview, showing a cell phone signalling to a device that is connected to a telescope mount and a camera.</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_overview.svg&diff=3923File:Partem overview.svg2020-11-17T21:35:22Z<p>Danny: </p>
<hr />
<div>Overview showing a cell phone signalling to a hardware device that is connected to a telescope mount and a camera.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3922WiFi telescope and camera control2020-11-14T15:00:37Z<p>Danny: /* Software */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I like to reuse whatever parts I have lying around, I used an old RJ-12 (telephone) socket for the connection to the camera.<br />
[[File:Partem electronics in enclosure.png|center|thumb|454x454px]]<br />
<br />
== Software ==<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In other words, expressed in the universal language of "Arduino":<syntaxhighlight lang="c++"><br />
void loop()<br />
{<br />
FromUdpToSerial();<br />
FromSerialToUdp();<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
And:<syntaxhighlight lang="c++"><br />
/**<br />
* Forward data that is received from the UDP port to the<br />
* serial device.<br />
*/<br />
bool FromUdpToSerial()<br />
{<br />
auto packetSize = udp.parsePacket();<br />
if (packetSize > 0)<br />
{<br />
packetSize = std::min( packetSize, bufferSize);<br />
remoteIp = udp.remoteIP();<br />
remoteUdpPort = udp.remotePort();<br />
<br />
udp.read( bufferFromUdp, bufferSize);<br />
<br />
if (not HandleLocally( bufferFromUdp, packetSize))<br />
{<br />
serial.write( bufferFromUdp, packetSize);<br />
}<br />
<br />
return true;<br />
}<br />
<br />
return false;<br />
}<br />
</syntaxhighlight><br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.<br />
<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Schematic_stripboard_layout.png&diff=3921File:Schematic stripboard layout.png2020-11-14T02:33:01Z<p>Danny: Danny uploaded a new version of File:Schematic stripboard layout.png</p>
<hr />
<div>Illustration showing the component placement on the stripboard</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3920WiFi telescope and camera control2020-11-14T01:44:53Z<p>Danny: /* System overview */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]<br />
<br />
To finish it off, the board is fitted into a [https://www.thingiverse.com/thing:4652797 3D-printed enclosure]. Because I like to reuse whatever parts I have lying around, I used an old RJ-12 (telephone) socket for the connection to the camera.<br />
[[File:Partem electronics in enclosure.png|center|thumb|454x454px]]<br />
<br />
== Software ==<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.<br />
<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3919WiFi telescope and camera control2020-11-14T01:26:43Z<p>Danny: </p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]<br />
<br />
To finish it off, the board is fitted into a 3D-printed enclosure. Because I like to reuse whatever parts I have lying around, I used an old RJ-12 (telephone) socket for the connection to the camera.<br />
[[File:Partem electronics in enclosure.png|center|thumb|454x454px]]<br />
<br />
== Software ==<br />
The software receives UDP packets and sends their contents verbatim to the serial port and vice versa. When receiving UDP data, the firmware will first examine the contents to see if any switch on/off instructions are being sent. If so, the package is intercepted and the switches are operated accordingly. Any other data is forwarded.<br />
<br />
In order to examine the communication between the SynScan app and this device, a python script was written that implements a simplified version of the motor-controller side of the protocol. This is just enough to get the SynScan app to connect to either the python script directly over UDP or through the Wemos D1 over an USB connection with the device.<br />
<br />
Sources are available on [https://github.com/DannyHavenith/Partem/blob/master/src/Partem.cpp github].</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3918WiFi telescope and camera control2020-11-14T01:15:58Z<p>Danny: /* System overview */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]<br />
<br />
To finish it off, the board is fitted into a 3D-printed enclosure. Because I like to reuse whatever parts I have lying around, I used an old RJ-12 (telephone) socket for the connection to the camera.<br />
[[File:Partem electronics in enclosure.png|center|thumb|454x454px]]</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_electronics_in_enclosure.png&diff=3917File:Partem electronics in enclosure.png2020-11-14T01:15:05Z<p>Danny: </p>
<hr />
<div>Image of the stripboard, Wemos D1 mini and components fitted into a 3D-printed enclosure.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3916WiFi telescope and camera control2020-11-14T01:05:43Z<p>Danny: /* System overview */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
<br />
[[File:Partem stripboard.png|alt=|300x300px]]<br />
[[File:Schematic stripboard layout.png|alt=|300x300px]]</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3915WiFi telescope and camera control2020-11-14T01:04:31Z<p>Danny: /* System overview */</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
[[File:Partem stripboard.png]]<br />
[[File:Schematic stripboard layout.png]]</div>Dannyhttps://rurandom.org/justintime/index.php?title=Driving_the_WS2811_at_800_kHz_with_an_8_MHz_AVR&diff=3914Driving the WS2811 at 800 kHz with an 8 MHz AVR2020-11-14T01:01:02Z<p>Danny: Attempt to correct syntax highlighting.</p>
<hr />
<div>This page describes how to drive a WS2811 from an 8Mhz or 9.6Mhz AVR like an Atmel ATmega88, ATtiny2313 or ATtiny13 '''without added components''' such as an external oscillator. With only 30 instructions for the driver loop (110 bytes for the complete function), the driver code presented here is likely to be the [https://github.com/DannyHavenith/ws2811/blob/master/ws2811/ws2811_8.h#L49 shortest code] that delivers the exact timing (i.e. exactly 10 clock cycles for 1 byte, exactly 60 clock cycles for 6 bytes, etc.). With even less code a "sparse driver" for 9.6Mhz MCUs can drive long led strings with only a few bytes of buffer in RAM.<br />
<br />
Of course, if you're creating a hardware project that controls more than 1 LED, you're going to have to demonstrate it with a Knight Rider LED sequence (which, I just learned, is actually called a [https://en.wikipedia.org/wiki/Glen_A._Larson Larson] scanner)... The sources for all the demonstrations in these videos can be found on [https://github.com/DannyHavenith/ws2811 github].<br />
{|<br />
|- valign="top"<br />
|colspan="3"|{{#ev:youtube|mP7vBw4UeME|400|left|Knight Rider on Steroids ([https://github.com/DannyHavenith/ws2811/blob/master/effects/chasers.hpp])}}<br />
|- valign="top"<br />
|{{#ev:youtube|MdX45a3OFS0|300||the [https://hackaday.io/project/9393-wheres-my-christmas-light/log/50423-the-most-simplest-is-the-most-easiest where's my christmas light] project}}<br />
|{{#ev:youtube|_wkTtAk2V_k|300||"Water Torture" or "Lava Drops" demo ([https://github.com/DannyHavenith/ws2811/blob/master/effects/water_torture.hpp source code], [[WS2811 "Water torture"|details]])}}<br />
|{{#ev:youtube|jAm7nVRvY_I|300||[[Driving a large WS2811 LED string with an ATtiny13 and nothing else|Special sparse driver]] allows an attiny13 to drive arbitrarily large LED strings from 64 bytes of memory}}<br />
|- valign="top"<br />
|{{#ev:youtube|mItPxAtkuVI|300||Flares demo on an attiny13 ([https://github.com/DannyHavenith/ws2811/blob/master/effects/flares.hpp source code])}}<br />
|{{#ev:youtube|VM84Q1vWSZE|300||Fireflies!}}<br />
|{{#ev:youtube|otCWPGf6O6w|300||Fire without flies}}<br />
|}<br />
<div style="clear: both"></div><br />
==Download source code==<br />
The library is header-only. Using it is a matter of downloading the source code and including it in your AVR code. Example source code can be found [https://github.com/DannyHavenith/ws2811 here]. The code comes as an avr-eclipse project consisting for a large part of C++ demonstration code and the main driver function in assembly, in files [https://github.com/DannyHavenith/ws2811/blob/master/ws2811/ws2811_8.h ws2811_8.h] and [https://github.com/DannyHavenith/ws2811/blob/master/ws2811/ws2811_96.h ws2811_96.h] (for the 9.6Mhz version). <br />
<br />
I don't recommend trying to understand the assembly code by reading these sources. How the code functions is described [[#Defining the puzzle|below]]. Usage information is in [[#Usage|the next section]]. The rest of this page describes the 8Mhz version. The 9.6Mhz code was added later, but is created in the same way.<br />
<br />
'''New:''' If you'd like to see the assembly code in action, take a look at the [http://rurandom.org/avrgo_demo/ online AVR emulator]!<br />
[[File:Avrgo demo screenshot.png|400px|link=https://rurandom.org/avrgo_demo/]]<br />
<br />
==Usage==<br />
You'll need the C++ compiler for this to work (turning ws2811.h into "pure C" is left as an exercise to the reader). I am told that this works just as good for an Arduino, but I haven't tested this myself. Remember that this code was written and optimized for 8Mhz and 9.6Mhz, it would run too fast on an 16Mhz Arduino. From the sources, you'll need files ''ws2811.h'', ''ws2811_8.h'', ''ws2811_96.h'' and ''rgb.h'', though you only include "ws2811.h". A simple example of how to use this code:<br />
<br />
<syntaxhighlight lang="c++"><br />
#include <avr/io.h> // for _BV()<br />
<br />
#define WS2811_PORT PORTD// ** your port here **<br />
#include "ws2811.h" // this will auto-select the 8Mhz or 9.6Mhz version<br />
<br />
using ws2811::rgb;<br />
<br />
namespace {<br />
const int output_pin = 3;<br />
rgb buffer[] = { rgb(255,255,255), rgb(0,0,255)};<br />
}<br />
<br />
int main()<br />
{<br />
// don't forget to configure your output pin,<br />
// the library doesn't do that for you.<br />
// in this example DDRD, because we're using PORTD.<br />
DDRD = _BV( output_pin);<br />
<br />
// send the RGB-values in buffer via pin 3<br />
// you can control up to 8 led strips from one AVR with this code, as long as they<br />
// are connected to pins of the same port. Just <br />
// provide the pin number that you want to send the values to here.<br />
send( buffer, output_pin);<br />
<br />
// alternatively, if you don't statically know the size of the buffer<br />
// or you have a pointer-to-rgb instead of an array-of-rgb.<br />
send( buffer, sizeof buffer/ sizeof buffer[0], output_pin);<br />
for(;;);<br />
}<br />
</syntaxhighlight><br />
<br />
==History==<br />
WS2811 LED controllers are hot. Projects using WS2811 (or WS2812, WS2812B or NeoPixel) LED strips have been featured on [http://hackaday.com/?s=ws2811 HackaDay] several times in the last few months. One feature showed how an AVR clocked at 16Mhz could send data at the required high rates. Inspired by this, I ordered an LED strip and 16Mhz oscillators from ebay. The LED strip arrived quickly, only the oscillators took weeks to arrive, which gave me plenty of time to think about the possibility of driving these led strips from an 8Mhz atmega88 without an external oscillator. With only 10 clock ticks per bit, this was going to be a challenge. <br />
<br />
Normally I'd go straight to the datasheet and start working from there, but in this particular case the datasheets are [http://www.nooelec.com/files/WS2811.pdf not so very informative]. Luckily, the HackaDay links provide some excellent discussions. [http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html This one] by Alan Burlison is especially helpful. That article not only explains in great detail why a library like FastSPI isn't guaranteed to work, but it comes with working code for a 16Mhz AVR that appears rock solid in its timing.<br />
<br />
Small problem: I didn't have any 16Mhz crystals on stock, so I ordered a few, on ebay again and sat back for the 25 day shipping time to pass. 25 Days is a long time. The led strip had arrived and was sitting on my desk. 25 Days is a really long time. Maybe it could work off an AVR on its internal 8Mhz oscillator? It would be a lot of work. But 25 days is a very, very, long time.<br />
<br />
So, that is how I got to sit down and write my 8Mhz version of a WS2811@800Khz bit banger. The challenge is of course that I have 10 clock cycles for every bit, no more no less, and 80 cycles for every byte, no more no less. '''I wanted the timing to be as rock-steady as Alan's''', give-or-take the imprecise nature of the AVR internal oscillator. The part about it being steady was important to me. People have argued that the code can be made a lot easier if you're willing to have a few extra clock cycles in between bytes or triplets and that such code works for them. I agree that such code is a lot easier to create or read. It's trivial, in fact. However, the WS2811's datasheets are ambiguous at best with regards to the maximum allowed delay between bytes (or bits) and anyway, I liked the challenge of trying to have zero clock ticks delay between bytes or triplets.<br />
<br />
==The challenge==<br />
For a full description of the required protocol to communicate with a WS2811, please refer to either [http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html Alans page] or the [http://www.nooelec.com/files/WS2811.pdf datasheet]. In summary, the microcontroller should send a serial signal containing 3 bytes for every LED in the chain, in GRB-order. The bits of this signal are encoded in a special way. See the figure below.<br />
<br />
[[File:Ws2811 waveform.png|illustration of a WS2811 waveform]]<br />
<br />
This image shows a sequence of a "0" followed by a "1". Every bit starts with a rising flank. For zeros, the signal drops back to low "quickly" while for ones the signal stays high and drops nearer the end of the bit. I've chosen the following timing, in line with Alans observations and recommendations:<br />
*Zero: 250ns up, 1000ns down<br />
*One: 1000ns up, 250ns down<br />
Giving a total duration of 1250ns for every bit, or 10&mu;s per byte. These timings do not fall in the ranges permitted by the data sheet, but Alan describes clearly why that should not be a problem. 1250ns means '''10 clock ticks per bit'''. That is not a lot. A typical, naive implementation would need to do the following things at every bit:<br />
# determine whether the next bit is a 1 or a 0<br />
# decrease a bit counter and determine if the end of a byte has been reached, if at the end:<br />
## determine if we're at the end of the total sequence<br />
## load a new byte in the data register<br />
## decrement the byte counter<br />
## reset the bit counter<br />
# jump back to the first step<br />
Oh yes, and that is of course in addition to actually switching the output levels.<br />
<br />
All of that does not fit into a single 10-clock time frame. Luckily, it doesn't have to. My first version of this driver partially unrolled the bit loop into a 2-bit loop. This allowed all those actions described above to fit within the loop, but it also required 4 versions of the loop (one for every 2-bit combination). The code would jump from one version of the loop to the other as appropriate.<br />
<br />
When writing code for the 9.6 Mhz version and the [[Driving a large WS2811 LED string with an ATtiny13 and nothing else|version for sparse LED strings]] (strings where most LEDs were off), I figured out a way where I could basically have one small loop for each bit but where the code for the last two bits would be unrolled, giving enough time to fetch the next byte and reset the bit counter. This resulted in the much smaller driver code that I have now.<br />
<br />
==Defining the puzzle==<br />
===Inventing a notation===<br />
Juggling with many states, jumping from one piece of code to the other without introducing phase errors turns out to be ''interesting''. I spent a couple of lonely lunch breaks and several pages in my little (paper!) notebook before I even figured out how to describe the problem. When a notation became clear, however, the going was easy enough and this exercise turned into one of the nicer kinds of pastimes. <br />
<br />
[[File:Ws2811 driver code.png|link=https://github.com/DannyHavenith/ws2811/blob/master/design/ws2811@8Mhz.ods?raw=true]]<br />
<br />
The image above shows the full code for the driver in a spreadsheet with pseudo assembly code in the yellow blocks. To the left of each yellow block is a graphic representing the wave form being generated. Tilt your head to the right to see the more conventional waveform graphic. The blue blocks show where the signal could be high or low, depending on the current bit value being sent. Each horizontal row in the yellow blocks represents a clock tick, not necessarily an instruction word. To the left of each waveform graphic there are numbers from 00 to 19 that represent the "phase" at the corresponding clock tick. Phases 00-09 are those of the first 7 bits, phases 10-19 are those of the last bit.<br />
<br />
What makes this notation so convenient is the fact that I can now easily determine the waveform phase at each point in the code and can also check whether a jump lands in the correct phase. Each jump at phase n (0 <= n < 09) should land at a label which is placed at phase n + 2 (modulo 10), because jumps take 2 clock cycles. Put differently: each jump should be to a label that is two lines down from the jump location (or 8 or 18 lines up).<br />
<br />
The drawn waveforms make it easy to verify that when I jump from the middle of a wave, the code lands in a place where that same wave form is continued. It also shows clearly where the 'up' and 'down' statements that do the actual signal levels need to go.<br />
<br />
Wherever there is a "^^^" in the table, it means that the previous instruction takes 2 clock cycles, so that particular clock cycle still belongs to the previous instruction.<br />
<br />
===How the code works===<br />
In summary, the code works as follows: The start of a bit waveform occurs at label ''s00''. At this point the value of the bit to be sent is assumed to be in the carry flag. The line is pulled high and if the current bit (carry flag) is a zero bit, it is pulled low two clock cycles later. Then a bit counter is decreased and if we're not in the second-to-last bit, we continue the second half of the waveform by jumping to label ''cont06'', which is above ''s00''. From ''cont06'' the code just waits a while, then brings the line down (which has no effect if the line was already brought down) and shifts the next bit from the data byte into the carry flag. From here the code falls back into label s00, ready to transmit the next bit.<br />
<br />
If we were in the second-to-last bit, the code continues downward after label ''skip03''. We need to free up the data register for the next byte, so we quickly test the last bit of the current byte and then branch into one of two essentially equivalent pieces of code. The code on the left hand side generates a "1"-waveform, while the code on the right generates a "0" for the last bit of the byte. In between the '''OUT'''-instructions we find some free cycles to reset the bit counter (to 7), to load the next byte and to decrease the 16-bit byte counter. If indeed there is a next byte to send, we jump up to either label ''cont07'' or ''cont09'' where the rest of the bit waveform is generated before we continue with the bits of the next byte.<br />
<br />
==Combining the code==<br />
The latest version of the code is pretty small (32 instructions/64 bytes), but earlier versions were bigger, requiring jumps over longer address distances. This posed a problem, because a jump from the end of the code right to the beginning would be too long for the branch instructions of the AVR.<br />
<br />
Note how all conditional jumps are in the form of branch instructions ("BRCC", "BREQ", etc). There is one important limit to these relative branches, they can only jump to a range of [PC - 63, PC + 64] (with PC the address of the jump instruction)! Any instruction more than 64 instructions away from the branch cannot be reached.<br />
<br />
At first I tried to piece the code together manually in a spreadsheet that would calculate the maximum jump distance for me. After a few failed attempts I gave up and decided that computers are better at this. In the end, I just wrote a [[Arrange timed code.cpp|dedicated program in C++]] that uses some common sense heuristics to shuffle the blocks of code around until it finds a sequence in which all jumps are within range.<br />
<br />
After this, it became a matter of just pasting the code blocks into one sequence and changing some of the pseudo instructions into real instructions.<br />
<br />
==Summary==<br />
The main point of this text is ''not'' that I can show 4 (four!) Larson scanners in one led strip. Actually there are two different points I ''am'' trying to make:<br />
<br />
First of all, it is possible to control WS2811 led strips from an AVR without external 16 Mhz oscillator with clock-tick-exact timing and I want to tell the world.<br />
<br />
Secondly, during this exercise I discovered that this kind of extremely time-critical code can be solved with a number or techniques:<br />
* unrolling loops. That is not a new technique, but in this case it not only saves on the number of test-and-jump-to-the-starts (the normal reason to unrol a loop), but also decreases the number of other tests and allows me to sweep a few precious left-over clock cycles into contiguous blocks.<br />
* Write a conditional jump in such a way that the jump is made in case there is not much left to do, saving a precious clock cycle for the busy case. Ignore the reflex to jump in "exceptional cases", trying to minimize the total number of times a jump is made.<br />
* when code is "phase critical", abandon the idea of a list-of-instructions and organize the code in "phase aligned" side-by-side blocks, where a jump is most often a jump "to the right" or "left".<br />
* Use software to optimize code layout in memory. I am not aware of any assembler that will automatically do this when jump labels are out of reach, but I know I have wished for it more than once.<br />
<br />
==Comments? Questions?==<br />
{{ShowComments|show=True}}<br />
<br />
[[Category:AVR]][[Category:WS2811]]</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3913WiFi telescope and camera control2020-11-14T00:59:02Z<p>Danny: Adding simple schematics to the system overview.</p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]<br />
<br />
==System overview==<br />
The system consists of a Wemos D1 mini, two BS170 N channel Mosfets, used as switches and a mini DC-DC buck converter. This connects to the RJ-45 socket on the EQM-35 mount, where it takes 12V power and connects to the 3.3v serial Rx and Tx lines.<br />
<br />
Two of the D1's GPIO pins control the mosfets while the D1's serial port lines can be connected directly to the serial port of the mount. Just to be sure, I've added 100R resistors on the serial lines. <br />
<br />
Overal, the schematic is so simple that this could be implemented on stripboard.<br />
[[File:Partem stripboard.png|left|thumb]]<br />
[[File:Schematic stripboard layout.png|thumb]]</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Schematic_stripboard_layout.png&diff=3912File:Schematic stripboard layout.png2020-11-14T00:58:11Z<p>Danny: </p>
<hr />
<div>Illustration showing the component placement on the stripboard</div>Dannyhttps://rurandom.org/justintime/index.php?title=File:Partem_stripboard.png&diff=3911File:Partem stripboard.png2020-11-14T00:56:24Z<p>Danny: </p>
<hr />
<div>Image of the strip board of the WiFi bridge. Backlighting shows clearly where the traces have been cut.</div>Dannyhttps://rurandom.org/justintime/index.php?title=WiFi_telescope_and_camera_control&diff=3910WiFi telescope and camera control2020-11-13T07:59:11Z<p>Danny: </p>
<hr />
<div>I'm so happy with my new telescope! This Skywatcher 150mm telescope (150P-DS) came with a decent motor-controlled mount with go-to capability (EQM-35 Pro). Out of the box, it comes with a SynScan hand controller, which is fine, if somewhat tedious to use. However, when using this mounts go-to capabilities with a WiFi bridge (instead of the hand controller) and the SynScan Pro app this telescope is a pure joy to use.<br />
<br />
The app also has a function to control a camera attached to the mount controller. Unfortunately, the EQM-35 Pro is not equipped with a SNAP port, the port to which a camera can be connected, so with a regular WiFi adapter, you can't use that functionality.<br />
<br />
It would be nice to have a WiFi-to-serial bridge that could also implement the camera controls sent by SynScan Pro app. And luckily, with cheap WiFi enabled microcontrollers available, this is relatively easy to do!<br />
<br />
[[File:Telescope and camera.png|alt=Telescope and camera|Telescope and camera|629x629px|left|thumb]]</div>Danny