Simplified Sidereal Time

While preparing for a full moon / blue moon, I was looking at an algorithm for calculating sidereal time and had a mini epiphany. The algorithm is basically an elaborate modulo operation. Modulo is generally applied to integer values, but it can be used with decimal numbers and even fractions.

For the algorithm that I have generally used, a lot of the calculations are only for converting the date to some linear expression of time. The calendar that is usually used does not express time linearly.

The amount of time from the beginning of one month to the beginning of another month could be 28 to 31 days. With linear representations of dates, a subtraction operation is all that is needed to know the amount of time between two moments in time.

In JavaScript, this linear representation of time is shown by calling getTime() on a date object. The time value for 2019 January 10 @16:40:20 UTC  is 1547138420000. This value is the number of milliseconds since another date and time. This time and date is also 00:00:00 Sidereal time. The number of milliseconds in a sidereal day (23 hours 56 minutes 4.1 seconds) is 86164100. For any date after 2019-01-10T16:40:20 we could get the Sidereal time by doing the following:

  • Acquire the getTime() value for the date in question.
  • Subtract 1547138420000 from that value.
  • Get the modulo 86164100 for the resulting value.
  • Multiply the result by 24/86164100.

The result of these operations is the sidereal time in decimal. If you want to convert it to hour:minute:second format do the following:

var hour = Math.floor(result);
var minute = (result % 1) * 60;
var second = (minute % 1) * 60;
minute = Math.floor(minute)




NodeJS on BrightSign

When I left off I was trying to achieve data persistence on a BrightSign  (model XT1144) using the typical APIs that one would expect to be available in an HTML application. To summarize the results, I found that using typical methods of checking localStorage and indexedDB show as being available; but indexedDB isn’t actually available; and localStorage appears to work, but doesn’t survive a device reset.

The next method to try is NodeJS.  The BrightSign devices support NodeJS, but the entry point is different than a standard entry point of a NodeJS project. A typical NodeJS project will have its entry point defined in a JavaScript file. For BrightSign, the entry point is an HTML file. NodeJS is disabled on the BrightSign by default. There is nothing in BrightAuthor that will enable it. There is a file written to the memory card (that one might otherwise ignore when using BrightAuthor) that must be manually modified. For your future deployments using BrightAuthor, take note that you will want to have the file modification described in this article saved to a back-up device so that it can be restored if a mistake is made.

The file, AUTORUN.BRS, is the first point of execution on the memory card. You can look at the usual function of this file as being like a boot loader; it will get your BrightSign project loaded and transfer execution to it. For BrightSign projects that use an HTML window the HTML window is actually created by the execution of this file. I am not going to cover the BrightScript language. For those that were ever familiar with the language, it looks very much like a variant of the B.A.S.I.C. language. When an HTML window is being created it is done with a call to the CreateObject method with “roHtmlWidget” as the first parameter to the function. The second parameter to this call is a “rectangle” object that indicates the coordinates at which the HTML window will be created. The third (optional) parameter is the one that is of interest. The third parameter is an object that defines options that can be applied to the HTML window.  The options that we want to specify are those that enable NodeJS, set a storage quota, and define the root of the file system that we will be accessing.

The exact layout of your Autorun.js may differ, but in the one that I am currently working with, I have modified the “config” object by adding the necessary parameters. It is possible that in your AutoRun.brs that the third parameter is not being passed at all. If this is the case, you can create your own “config” object to be passed as a third parameter. The additions I have made are in bold in the following.

is = {
    port: 3999
security = {
        websecurity: false,
        camera_enabled: true
config = {
    nodejs_enabled: true,
    inspector_server: is,
    brightsign_js_objects_enabled: true,
    javascript_enabled: true,
    mouse_enabled: true,
    port: m.msgPort,
    storage_path: "SD:"
    storage_quota: 1073741824            
    security_params: {
        websecurity: false,
        camera_enabled: true
    url: nodeUrl$
htmlWidget = CreateObject("roHtmlWidget", rect, config)

Once node is enabled the JavaScript for your page will run with the capabilities that you would generally expect to have in a NodeJS project. For my scenario, this means that I now have acces to the FS object for reading and writing to the file system.

fs = require('fs');
var writer = fs.createWriteStream('/storage/sd/myFile.mp4',{defaultEncoding:'utf16le'});
writer.write("Hello World!\r\n");

I put this code in an HTML page and ran it on a BrightSign. After inspecting the SD card after the device booted up and was on for a few moments I saw that my file was still there (Success!).  Now I have a direction in which to move for file persistence.

One of the nice things about using the ServiceWorker object for caching files is that you can treat a file as either successfully cached or failed. When using a file system writer there are other states that I will have to consider. A file could have partially downloaded, but not finished (due to a power outage; network outage; timeout; or someone pressing the reset button; etc.). I’m inclined to be pessimistic when it comes to guaging the reliability of external factors to a system. I find it necessary to plan with the anticipation of them failing.

With that pessimism in mind, there are a couple of approaches that I can immediately think to apply to downloading and caching files.  One is to download files with a temporary name and change the name of the file from its temporary to permanent name only after the download is successful. The other (which is a variation of that solution) is to download the file structure to a temporary location. Once all of the files are downloaded, I could move the folder to its final place (or simply change the path at which the HTML project looks to load its files). Both methods could work.

I am going to try some variations of the solutions I have in mind and will write back with the results of one of the solutions.


Chrome 74: What is New for Developers


Chrome  74 has been released. The most notable user facing feature is dark mode. It has a number of API updates for developers too. Some of those updates include the following (but there are more)

    • Private class Fields
    • Reduced Motion Experience
    • CSS Transition Event
    • Feature Policies
    • KV Storeage API
    • Buffering of client.postMessage()

Private Class Fields

Fields on classes can now be declared as private by prefixing them with #. Consider the # to be part of the members name. Members marked with this character are not accessible outside of the class.

Reduced Motion Experience

There are people that might experience motion sickness from web pages with lots of scrolling and parallax. A new media query was added so that an experience with less motion can be provided to users that are sensitive to it.


CSS Transition Event

Other browsers have supported CSS transition events. Until now Chrome hasn’t been one of them. With the release of Chrome 74 transition events are now supported. The names of the events are

  • transitionrun
  • transitionstart
  • transitionended
  • transitioncancel

Feature Policies

Some APIs can be selectively enabled or disabled through a Feature-Policy header or through an allow attribute on an iframe. The list of features allowed can be queried with document.featurePolicy.allowedFeatures()

KV Storage API

Storage through localStorage is slow (it’s synchronous). While IndexedDB is asynchronous it’s a more complex API.  To provide a faster API that is easier to use Google has added support for the Key Values Storage API.  There is also a KV polyfill for browsers that do not support KV Storage.

Buffering of client.postMessage()

Messages sent via client.postMessage() are now buffered until a document is ready. a call to postMessage doesn’t dispatch until either DOMContentLoaded is fired, onmessage is set, or startMessages() is called.

NVIDIA Jetson Development Environment Setup

In previous posts on the NVIDIA Jetson posts I’ve talked about getting the device setup and some additional accessories that you may want to have. The OS image for the NVIDIA Jetson already contains a compiler and other development software. Technically someone can start developing with the OS image as it is when it ships.  But it is not desirable to develop this way.

There may be some things that you prefer to do on your primary computer and you’d like to be able to control the Jetson from your primary machine. The OS image for the Jetson already has SSH enabled. If you are using a Windows machine and net an SSH client I suggest using PuTTY for Windows. It’s a great SSH client and also works as a telnet or serial console when needed. It’s available from

When Putty is opened by default it is ready to connect to a device over SSH. You only need to enter the IP address to start the connection. Once connected enter your account name and password and you’ll have an active terminal available. For copying files over SSHFTP I use WinSCP (available from

For development on the device I’ve chose Visual Studio Code as my IDE. Yes, it runs on ARMs too.  There are a number of guides available on how to get Visual Studio Code recompiled and installed for an ARMS system. The one that I used is available from In a nutshell I followed two steps; I entered a super user session with the command

su -s

Then I ran the following (which downloads a script from the head melted site and runs it).

sudo apt-key adv --keyserver --recv-keys 0CC3FD642696BFC8^C
. <( wget -O - )

The script only takes a few moments to run. After it’s done you are ready to start development either directly on the board or from another machine.

To make sure that everything works let’s make our first program with the Jetson Nano. This is a “Hello World” program; it is not going to do anything substantial. Let’s also use make to compile the program. make will take care of seeing what needs to be built and issuing the necessary commands. Here it’s use is going to be trivial. But I think starting with simple use of it will give an opportunity for those that are new to it to get oriented with it. Type the following code and save it as


__global__ void cuda_hello()
    printf("Hello World from GPU!\n");

using namespace std;

int main()
	cout << "Hello world!" << endl;
	return 0;

We also need to make a new file named makefile. The following couple of lines will say that if there is no file named helloworld (or if the file is out of date based on the date stamp on the to compile it using the command /usr/local/cuda/bin/nvcc -o helloworld

   usr/local/cuda/bin/nvcc -o helloworld

Note that there should be a tab on the second line, not a space.
Save this in the same folder as helloworld.cs.

Type make and press enter to build the program. If you type it again nothing will happen. That’s because make sees that the source file hasn’t changed since the executable was build.

Now type ./helloworld and see the program run.

Congratulations, you have a working build environment. Now that we can compile code it’s time to move to something less trivial. In an upcoming post I’ll talk about what CUDA is and how you can use it for calculations with high parallelism.

NEWS:Linux on Dex Coming to More Devices


Samsung has announced that Linux on Dex is coming to more devices. Previously it was only available on non-LTE models of the Galaxy Tab S4 and on the Galaxy Note 9. Per an email that Samsung sent on Monday support is coming to the Android Pie builds of the  S9, S9+, S10e, S10+, Tab S4, and Tab S5e.

Based on interaction with others (and also being my own personal story) there are owners of the TAB S4 that haven’t yet received Linux on Dex support that wait with anticipation for support to come. I’ve not been able to confirm compatibility yet as the Pie build of Android isn’t yet available for my device. The Linux on Dex page had previously stated that none of the LTE Tab S4 models were supported. The page now only states that the Verizon LTE tablets are not supported.  I hope that this means that support for my device is coming. For now the only option is to wait.

Update (2019-April 30): Today I received the Android Pie update for the Galaxy Tab S4. It does indeed have support for Linux on Dex (finally!).

NVIDIA Jetson Nano Shopping List

Jetson Nano Packaging

I had made a video posted to YouTube about the Jetson Nano and the additional items that I purchased for it. This is a complete list of those items and some extras (such as memory cards of some other sizes).


General Items

Memory Cards


Items I Found Helpful