Gas station without pumps

2019 December 3

Moved PteroDAQ from BitBucket to GitHub

Filed under: Circuits course — gasstationwithoutpumps @ 18:00
Tags: , , , ,

As mentioned in BitBucket being killed by Atlassian, Atlassian is killing off all its Mercurial repositories in BitBucket, forcing people to change to git.  They provide no tools for moving the repository, so it is easier to move to GitHub than to stay with BitBucket.

I have successfully moved the repository (using Github’s “import repository” drop-down menu item under the “+” tab, and moved over the issues, using the python program from

Because the PteroDAQ wiki had only two files, I moved them to the new repository manually, renaming the to and editing the files lightly to update any BitBucket links.

I’ve even updated the link on the sidebar of this blog to point to the new Github repository.  It would be useful if one of my readers could check that the new repository works and that the installation instructions are ok.  I had no trouble, but I’m the owner of the repository, which makes a difference.

The new repository is at

2019 September 5

Move to Github half done

Filed under: Uncategorized — gasstationwithoutpumps @ 11:36
Tags: , , , ,

As I mentioned in BitBucket being killed by Atlassian, I am moving all my BitBucket Mercurial repositories to GitHub as Git repositories.  So far, I’ve moved my two private repositories (my textbook and a beacon-dectector project), because they had no wiki or issues associated with the repository.  Moving them to GitHub was very easy, as GitHub has an importer that does almost all the work of importing the repository itself from BitBucket.  Unfortunately, their importer supposedly does not handle importing the issue history nor the wiki, which is a shame.

That leaves me with the harder task of importing the  PteroDAQ project, which I’ll have to do in the next month, because there are pointers to it in my book, and these pointers will need to be updated for the end-of-December release.  There are some scripts on the web for doing the issue and wiki transfers, but they are not part of the standard GitHub suite of tools, and may be a bit iffy.  I’ll wait a little while to see whether there is a consensus on the best way to do the transfer (or whether GitHub provides a more powerful import tool).

I have not learned the git command-line tools yet, as I’ve been using GitHub Desktop to manage my new repositories.  Given that they have only the single main branch, no issue tracking, and nothing else fancy, I think that this GUI may be all I need.  I did have to create a .gitignore file that was a little more comprehensive than my .hgignore file was, to make sure that git did not pick up a bunch of intermediate files that shouldn’t be part of the repository.


2019 August 26

BitBucket being killed by Atlassian

Filed under: Uncategorized — gasstationwithoutpumps @ 17:01
Tags: , , , ,

I have been using BitBucket for source code repositories since about 2012, when my son chose it for the Arduino data logger project, which later became the PteroDAQ project (in a separate BitBucket repository).  This month Atlassian decided to end support for all Mercurial projects, with no new repositories after February 2020, and deletion of all remaining repositories in June 2020.

I will have to move PteroDAQ from BitBucket well before the deadline, because there are pointers to it in my book, and these pointers will need to be updated for the end-of-December release.

I think that Atlassian’s tone-deaf announcement will kill off BitBucket as a source-code hosting site, even though they plan to continue to support git.  Who will trust them to maintain repositories if they plan to delete everything some group of their customers have relied on them for?  I could sort of understand stopping support for Mercurial (though that was the main thing that made BitBucket better than GitHub), but the result should have been making the repositories read-only for ten years, not deletion.  Atlassian picked up a bunch of users from GitHub when Microsoft bought GitHub, but I think that they will lose a lot of them from this managerial mistake.

Making things worse, Atlassian is providing no automation to convert repositories from Mercurial to Git, suggesting that people do the move(s) manually.  Even GitHub provides better tools, with an automatic import of Mercurial repositories that even maps authors.

The net effect of Atlassian’s managerial decision will not be migration from BitBucket Mercurial to BitBucket Git, but to GitHub or GitLab.  GitHub or GitLab could accelerate this migration by providing an automatic import that moves the wiki and issues database from BitBucket at the same time.

I moved one repository to GitHub, just to see how well the automatic import of the repository worked.  That repository had no wiki or issue tracking, so was easy to move.  I’ll probably move my book sources to GitHub also, after the next push I do to the BitBucket repository.  (I considered using GitLab instead of GitHub, but they don’t seem to have an automatic transfer of Mercurial repositories from BitBucket, the way that GitHub does.)

The PteroDAQ move will be the most difficult, because I’ll want to move the issues and the wiki as well.  There seem to be some scripts on the web for doing those transfers, but they are not part of the standard GitHub suite of tools, and may be a bit iffy.


2012 December 31

Data logging software for circuits course working

Over winter break, my son has been working nearly full time on writing data logging software for my students to use in the Applied Circuits for Bioengineers course. He has made the first public beta release (v1.0.0b1) today on BitBucket. (Note: you may have to click on the “tags” tab to get to the view that shows the v1.0.0b1 link. The BitBucket link directly to that view seems to be broken—that’s open issue 5504 in BitBucket’s own issue tracker.)

We’ve only tested the code on Mac OS X computers with Arduino Duemilanove and Uno boards, though we’ve tested a slightly earlier version on Windows.  The code should also run on Linux and with Leonardo and Mega boards, but has not been tested on these platforms. We welcome users testing the code for us—report any problems using the BitBucket issue tracker for the project.  The documentation is still in a fairly primitive state—report issues with that also, so that they can be fixed.

The overall goal is fairly simple: to have an easy-to-use way to record timestamps, voltages, and digital values from the Arduino into files on a host computer, without needing auxiliary hardware (like the Adafruit data logger shield that I bought for myself and assembled yesterday).

The user can specify what analog and digital pins to record and when to record the values.  When to record can be specified either   as interrupts on pins or as fixed timing intervals:

View of the two windows of the user interface.

View of the two windows of the user interface.

The “volts measured” for the reference is stored as metadata in the output file and can be used for scaling the Arduino numbers (if “Convert to Volts” is checked).  The scaling can be an arbitrary value for the full-scale reading or can be the voltage measured with an external multimeter at the AREF pin.

This software has been through several versions:

  1. The first version of the code was one I wrote last spring that just recorded interrupt times in an Arduino array and dumped them out over the USB cable after it was done (see Homemade super pulley).
  2. My son was not happy with that crude program of mine and rewrote it in June to have use the Arduino memory as a queue and send the time stamps to a Python program on the laptop (see Improved super pulley code).  That program introduced him to three new concepts: circular buffers for queues, interrupts, and multi-threading, all of which he researched for himself. That version of the code mainly used a command line interface, but he used the curses package for a crude user interface.
  3. He added a PyGUI graphical user interface, but that slowed down the code on the laptop and eventually grew to be difficult to maintain.
  4. He decided to try to make the software by portable between three platforms (Mac OS X, Windows, and Linux) despite their very different ways of dealing with the USB serial ports, to run under both Python2.7 and Python3, and to require only minimal non-standard packages (mainly PySerial and the Arduino package Timer1).  He refactored the code completely and built the GUI using Tkinter. This has lead to the current version of the code, which is finally working robustly enough to let the bioengineering students use it.

It has been a good software-engineering experience for my son, and he has learned a lot.  In the process of developing this code, he has learned a lot about interrupts, using queues to communicate between processors and between threads, platform-independence, a couple of different GUI libraries, the value of version control and bug-tracking, race conditions, interface design for non-expert users, and even some things about documentation.

I’ve been acting mainly as a customer for this code, entering bug reports and suggesting new features, though I have occasionally helped him debug.  For example, we just spent fifteen minutes reading Section 15 “16-bit Timer/Counter1 with PWM” of the ATMega328 data sheet, trying to figure out why the first time interval was wrong.  It turns out that timer interrupt is raised immediately when the interrupt is enabled, unless the timer-overflow flag is turned off first.

My son may use this project as a science fair entry this year, though it was not started with that idea, and we discussed that possibility for the first time today.  The big problem is that this is purely an engineering project, not a “science” project, and trying to fake a hypothesis is not something we’ll consider.


%d bloggers like this: