[{"_1":2,"_32":-5,"_33":-5},"loaderData",{"_3":4},"routes/blog",{"_5":6},"posts",[7,20,26],{"_8":9,"_10":11,"_12":13,"_14":15,"_16":17,"_18":19},"id","F01F17fAl3TAr1kPmBkI","body","

Note: Later on in this guide, you'll have to add a billing method and change your newly created project to the \"Blaze\" plan. If you don't want to perform this, the SSR function won't be enabled.

Gitlab repo of this example is here... https://github.com/gonesurfing/vike-ssr

I've been using Firebase as a hosting tool for https://pinpointsurf.com for the last couple of years. The site is an SPA, utilizing the react set of tools and routing. While this works well for the highly dynamic nature of the applicaiton, it poses considerable challenges for search engine optimization (SEO). While googlebot will render the JS within the page, it does so very infrequently. It may only pass the site every couple of weeks, and only updates a few pages each time. Not really what we want if we're going to jump in search rankings. Showing google fast, fresh data should help ranking, while old infrequently updated data hurts.

A short term solution has been to use puppeteer to render the page if the request user-agent is \"googlebot\" or one of the other spiders. This has a few issues:

1) The app makes extensive use of mapbox-gl-js, and this runs client side only. Not rendering the map isn't currently an option as all my chart data for surf height and quality comes from within the mapbox application.

2) Because the application has to fully render the mapbox map inside of headless Chrome, it is sloooooow on a server and takes a lot of memory.

3) We have to run a non-cached firebase function to check if the user-agent is a bot, or a normal user request. Becaues of the way firebase works, we have to either pass the bot request to another function and wait for the return, or return index.html immediately. If the firebase function's index.html isn't updated when the bundler changes names, it will break the site. This also means we can't make use of CDN caching.

So to address this, we need to somehow accomplish a few things. The first, is to get an example Vite/Vike site up and working with Firebase. The logical place to start is to create a vike scaffold for the project. We'll use the project name \"vike-ssr\".

% npm init vike@latest\n✔ Project name: · vike-ssr\n\nScaffolding project in /.../vike-ssr...\n✔ Select a boilerplate: · react\n

The script tells us the next steps:

cd vike-ssr/\n  npm install (or pnpm install / yarn install)\n  npm run dev (or pnpm run dev / yarn dev)\n

Then were going to initialize firebase in our new project, and create a project. You'll need to have firebase CLI tools installed already, and be logged in to your account. For this, I'm going to use \"vike-ssr\" again as the project name, but since it has to be unique you'll have to modify this for your own project. Also, we're only going to initialize hosting and functions in the init program.

vike-ssr % firebase init\n\n     ######## #### ########  ######## ########     ###     ######  ########\n     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##\n     ######    ##  ########  ######   ########  #########  ######  ######\n     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##\n     ##       #### ##     ## ######## ########  ##     ##  ######  ########\n\nYou're about to initialize a Firebase project in this directory:\n\n  /.../vike-ssr\n\n? Which Firebase features do you want to set up for this directory? Press Space to select features, then Enter to \nconfirm your choices. Functions: Configure a Cloud Functions directory and its files, Hosting: Configure files for\n Firebase Hosting and (optionally) set up GitHub Action deploys\n\n=== Project Setup\n\nFirst, let's associate this project directory with a Firebase project.\nYou can create multiple project aliases by running firebase use --add, \nbut for now we'll just set up a default project.\n\n? Please select an option: Create a new project\ni  If you want to create a project in a Google Cloud organization or folder, please use \"firebase projects:create\" \\ \ninstead, and return to this command when you've created the project.\n? Please specify a unique project id (warning: cannot be modified afterward) [6-30 characters]:\n vike-ssr\n? What would you like to call your project? (defaults to your project ID) \n✔ Creating Google Cloud Platform project\n✔ Adding Firebase resources to Google Cloud Platform project\n\n🎉🎉🎉 Your Firebase project is ready! 🎉🎉🎉\n\nProject information:\n   - Project ID: vike-ssr\n   - Project Name: vike-ssr\n\nFirebase console is available at\nhttps://console.firebase.google.com/project/vike-ssr/overview\ni  Using project vike-ssr (vike-ssr)\n\n=== Functions Setup\nLet's create a new codebase for your functions.\nA directory corresponding to the codebase will be created in your project\nwith sample code pre-configured.\n\nSee https://firebase.google.com/docs/functions/organize-functions for\nmore information on organizing your functions using codebases.\n\nFunctions can be deployed with firebase deploy.\n\n? What language would you like to use to write Cloud Functions? JavaScript\n? Do you want to use ESLint to catch probable bugs and enforce style? No\n✔  Wrote functions/package.json\n✔  Wrote functions/index.js\n✔  Wrote functions/.gitignore\n? Do you want to install dependencies with npm now? Yes\n\nadded 537 packages, and audited 538 packages in 17s\n\n52 packages are looking for funding\n  run `npm fund` for details\n\nfound 0 vulnerabilities\n\n=== Hosting Setup\n\nYour public directory is the folder (relative to your project directory) that\nwill contain Hosting assets to be uploaded with firebase deploy. If you\nhave a build process for your assets, use your build's output directory.\n\n? What do you want to use as your public directory? dist\n? Configure as a single-page app (rewrite all urls to /index.html)? No\n? Set up automatic builds and deploys with GitHub? No\n✔  Wrote dist/404.html\n✔  Wrote dist/index.html\n\ni  Writing configuration info to firebase.json...\ni  Writing project information to .firebaserc...\n\n✔  Firebase initialization complete!\n

After completing the init dialog, you should have an initialized firebase project. First we're going to need to add some stuff to our firebase.json. Make sure the key under \"hosting\" to points to the client code. For Vike, this is \"dist/client\".

{\n  \"hosting\": {\n    \"public\": \"dist/client\",   \n...

Then, we need to point all the http hosting requests to our firebase function. We're going to call it \"ssr\".

\"rewrites\": [\n      {\n        \"source\": \"**\",\n        \"function\": \"ssr\"\n      }\n    ]

The last part we have to add is for pre-deploy to move the dist directory into our functions folder. Note: If you are using the firebase emulator locally, this predeploy step won't happen automatically. You'll have to run these commands from the command line for things to remain synced.

\"predeploy\": [\n        \"rm -rf functions/dist\",\n        \"cp -r dist functions\"\n      ]

Now we can add our rendering function \"ssr\" to our firebase functions. First, change to the functions directory and install a few node packages. Otherwise, the firebase function will crash at runtime.

cd functions \\\n   npm install vike react react-dom prop-types

And finally we can add our rendering function. This will render the site's HTML, and send it back to the client in the response. Copy this code, and paste it in functions/index.js

const {onRequest} = require(\"firebase-functions/v2/https\");\nconst logger = require(\"firebase-functions/logger\");\n// see: https://vite-plugin-ssr.com/importBuild.cjs\nrequire(\"./dist/server/importBuild.cjs\");\nconst {renderPage} = require(\"vike/server\");\n\n// Vike middleware.\n\nexports.vikeRender = onRequest(async (request, response) => {\n  const pageContextInit = {\n    urlOriginal: request.originalUrl,\n  };\n  const pageContext = await renderPage(pageContextInit);\n\n  if (!pageContext.httpResponse) {\n    logger.info(pageContext.httpResponse, request.originalUrl);\n    response.send(null);\n  } else {\n    const {body, statusCode, headers, earlyHints} = pageContext.httpResponse;\n    if (response.writeEarlyHints) {\n      response.writeEarlyHints({link: earlyHints.map((e) => e.earlyHintLink)});\n    }\n    headers.forEach(([name, value]) => response.setHeader(name, value));\n    response.status(statusCode);\n    response.send(body);\n  }\n});

Now, we can deploy. If you enabled eslint during init, you can address the errors by excluding the functions/dist directory.

% cd ..\n% nom run build\n% firebase deploy

Woops. We get an error that says we have to be on the Blaze (pay-as-you-go).

Error: Your project vike-ssr must be on the Blaze (pay-as-you-go) plan to complete this command. \\\n   Required API artifactregistry.googleapis.com can't be enabled until the upgrade is complete. \n\n

So unfortunately you'll have to log into firebase console and add a billing method and change from \"Spark\" to \"Blaze\". Then re-run \"firebase deploy\". If everything worked correctly, you be ablel to go to the url shown and the end of deploy (Hosting URL: https://vike-ssr.web.app) and see the vite react screen.

$\"\"$

FYI: The first time tried this process, I initialized the project in the Firebase console and then used it as an existing project in the CLI. After deploying, I was greeted with a \"Forbidden\" error in my browser. I'm not sure why the behavior is different for this workflow, but there is a way to resolve it. This is a little bit non-intuitive from a Firebase perspective, as it requires you to go through google-cloud-platform to resolve.

Navigate over to cloud console, and find your project at https://console.cloud.google.com. From there, go into the functions menu, but don't change anything there. You have to click from \"Functions\" through to the \"Cloud Run\" project that supplies the function. Under \"Security\" change Authentication to \"Allow unauthenticated invocations\". Confusing? Yes.

Now, you should finally be greeted by your freshly deployed Vike SSR application.

","created",1699745395000,"published",true,"title","Vike SSR Rendering","topics","Vite, Vike, SSR, SEO, Firebase",{"_8":21,"_18":22,"_12":23,"_16":24,"_10":25,"_14":15},"jCyYoFFpKfYRaRnC61iS","Cars, Electronics, Mercedes, 300CD, 300D, ATTiny85",1699109570794,"Re-Engineering the OM617 Glow Plug Relay","

I was faced with an all too typical problem when driving an old car. A single point of failure; some part that has been working pretty much correctly for decades, decides to give up.

Such as it was with my Mercedes glow plug system. The typical amber glow emminating from the dashboard at the turn of the key, and the sound of the 40 year old diesel turning over after a couple seconds of cranking weren't there. Instead, they were replaced with a bright red alternator light and the endless sound of an engine cranking with no hope of firing on a 50 degree Farenheit fall evening.

The series glow plug system is a known week spot on early OM617 engines that were manufactured in the mid to late 70's. In the early 80's, the system was redesigned with the plugs wired in parallel. This brings two advantages...

1) There is a full 12V supplied to each plug, and given ohm's law we can get more power from each plug without rediculous amounts of current.

2) If any one glow plug fails, the remaining plugs will still work. In other words, they aren't an old string of Christmas lights anymore.

There were kits availiable to retrofit the series glow system, but there was one concern I had with this route. The factory glow plug relay was still utilized to pass current to the plugs. On the older versions, this routes lots of current (80A) over frail wiring that passes through the firewall and back. I decided to come up with a way to still utilize the factory relay wiring, but wire in a high current relay under the hood for passing controlling the plugs. Below is a picture of the business side of the old OM617 relay. We can improve this and reduce the fire hazard while we're at it.

$\"\"$

To keep the function as factory as possible, I wanted the glow timer to automatically compensate for block temperature. This is something that the retrofit kits don't address. When it's very cold outside (cold being 30F/0C, here in NC) the plugs need to glow for a few seconds. When warm, they should only glow for a second. When the engine is hot, they shouldn't glow at all. Since the factory wiring already had the block sensor wired in, I didn't have to route anything else through the firewall. Rather than try to come up with an old-school R-C circuit that can compensate for sensor resistance and operate as a timer, I decided to throw a cheap microcontroller at it.

I am a fan of the 8 bit Atmel series microcontrollers. Prior to the pandemic, they were insanely cheap, availiable, and had just enough function packed into an 8 pin package to tackle simple jobs like this. Need a timer? AT-Tiny! Need to output a PWM signal? AT-Tiny! They can be used in the Arduino IDE/Framework, or programmed in plain old C. I prefer the latter, as you get to really understand how capable these things are. For this, I use PlatformIO to manage any libraries I need and run the avr-gcc compiler. Post-pandemic, supplies seem to be improving and the price is still reasonable for small quantity projects.

Since I don't need high accuracy on the timer, I'm going to utilize the onboard oscillator. This eliminates the need to take up two pins with an external oscillator. This is fine for this project, but things that need accurate timing will require it. The glow timer works by:

1) Doing an analog to digital conversion on the temperature sensor voltage.

2) Using the ADC value to compare against a lookup table stored in an array.

3) Using the return value from the lookup array to set up a timer.

From there, the logic is simple. Glow plugs on for x amount of time, then off. The program will continue to run with the output off until the power is cycled on the microcontroller (by action of turning the ignition off, and back on again).

Now, how long do the plugs need to stay on? Since these are considered \"fast\" glow plugs, the time required is very different from the old plugs. Time to dig into some old documentation. At some point, Mercedes-Benz decided to release the old factory service manuals for the W123 chassis and OM617 series engines. Buried somewhere in the \"preglow system\" manual, I found comparisons of the two systems, along with the required pre-glow time based on block temperature.

Below: The old curve (top) vs the new curve (bottom(a)).

$\"\"$ $\"\"$

In order for the microcontroller to know how long to glow the plugs, some conversion is needed. Since 8 bit microntrollers aren't designed to do lots of math, I went ahead and created a conversion array to map the 8 bit ADC value to the corresponding glow time.

One additional function that this controller retains from the original relay design: If the engine crank signal is detected before the glow plug timer expires, the plugs will turn off. Because this signal is 12V on the wiring harness, I used an opto-isolator to interface with the 5V microcontroller.

uint32_t glow_time = glow_data[adc_val] * 1000; // Convert to ms

The last step (after soldering the sytem on some perf board) was creating a housing to hold the new relay. Time to fire up the 3D printer! Since it's going inside a car, PLA isn't going to cut it. Instead I used PETG, as my Creality printer can handle it well and I've had decent luck at prints lasting inside the car on a hot day. I carefully cut some of the pins off of an old relay that I had, and designed the enclosure's harness mating surface to encapsulate them.

$\"\"$

After mouting the PCB and connecting the harness pins, it's time to button it up and install. So-far everything works well. There is a weird glitch when I switch on the AC compressor though. It seems the magnetic clutch current draw is enough to drop the voltage on the car's wiring just long enough to reset the microcontroller. This reset will fire the glow plugs for 1 second if the engine isn't yet at operating temperature. It only occurs when first engaging the AC compressor after starting the car, and can probably be solved by a larger capacitor on the incoming 12V supply to the LM7805 regulator.

$\"\"$

The schematic and microcontroller source code for the project can be found on my github page here. Perhaps one day I'll design a PCB for the circuit. For now, the perf board will suffice.

-Eric

",{"_8":27,"_18":28,"_14":15,"_12":29,"_16":30,"_10":31},"AsiZ5IzYpU3xmyo9jfvk","SDR Softrock Wolfson Quisk pulseaudio",1641437574264,"Using the Raspberry Pi and Wolfson Audio Card as a Remote Softrock Interface","

Note: this was originally on km4dsj.wordpress.com (my old callsign). I moved it here so It's availiable without all the ads. It is painfully out of date, but is here for posterity.

Errata: Quisk-3.7.8 has some errors associated with my hardware_net.py script. Quisk-3.7.7 is working.

Update: I gave a quick presentation on this setup at my local ham club meeting. Here is a link to the ppt slides.

I’ve only been a ham now for about 1 year, but since SDR and low power digital modes are what got me interested in this hobby, building an SDR HF setup was my first foray into the world of 2 way HF communication. Once I had the softrock RXTX Ensemble built, I wanted a way to interface with it such that I could use it with my laptop from anywhere in the house. I also wanted a small setup that didn’t take up lots of room and could hide out of sight. I had been testing the program Quisk and had good results with it connected directly to the softrock, so I opted to continue using it for this step of the project.

$\"Ham$

My \"shack\"

The basic RX path is: Antenna –(RF) -> Softrock RXTX –(I/Q audio)-> wolfson/pi -> pulseaudio -> Quisk –(baseband audio)-> pulseaudio -> speakers/fldigi The first step was to use a quality soundcard. I tested the softrock using a Burr Brown PCM2902 based USB interface, but wanted something that would do 96khz sampling rate. The Wolfson Pi seemed to be the best choice on the market, except for the fact that the drivers were not completely integrated into the raspberry pi kernel. This requires a little extra pain in the beginning for the card to be recognized. The steps below are assuming some basic familiarity with the pi and linux in general. I am currently using this setup to make contacts via PSK, RTTY, JT-65/JT-9. It’s also great for picking up shortwave broadcasts from around the globe. Steps below:

Note: If you already have a working sound card setup, you can skip to the pulseaudio configuration part, step 5.

1) Download the latest Raspian image from the raspberry pi website. Write the image to the SD card.

2) After booting Raspbian, log in using the user pi and default password. I do this using ssh, but you can plug in a keyboard and monitor if you aren’t familiar with that method. Run “sudo apt-get update” and then “sudo apt-get upgrade”. These two commands will ensure you have the most up-to-date distribution before we do any Kernel work. Go ahead and reboot the pi after this.

3) Install git on your local machine. Download the kernel source from Cirru’s github page and follow the directions linked below for cross compiling. On a 64 bit linux machine you’ll need to “sudo apt-get install lib32z1” or else the compile will fail early. Note: There is a pull request on the official raspberry pi/linux github, but I’ve had issues with the card not being detected with that version of the kernel. https://github.com/CirrusLogic/rpi-linux/wiki/Building-the-code

4) After installing the new kernel and modules, reboot the pi. Login and type “aplay -l”. Hopefully the following text appears. If not, something went wrong. Go back and check that the proper modules are being loaded and blacklisted.

\n
**** List of PLAYBACK Hardware Devices **** card 0: sndrpiwsp [snd_rpi_wsp], device 0: WM5102 AiFi wm5102-aif1-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
\n

5) Next you’ll have to install pulseaudio on the rpi. I’ve opted to build it from source (version 5.0), but version 3.0 is already available through apt-get. Note: I haven’t tested version 3.0 extensively. It may work great, it may work poorly.

6) Edit the pulseaudio configuration files on the raspberry pi. /etc/pulse/default.pa add “tsched=0” to the udev line so that it reads:

\n\n\n\n\n\n\n\n

load-module module-udev-detect tsched=0

A bit of education on Pulseaudio that took me a while to figure out. There are several methods to pipe audio over a network. This was not immediately clear to me at first, and a even the pulseaudio FAQ is a little vague on the different methods. They boil down to this:

Direct: Setting the client program to connect to a remote server either through through the API or setting “PULSE_SERVER=” when starting the program. This was the route I originally attempted to go . It uses TCP packets and seems fairly robust to network congestion or latency. However, there was a showstopper bug where after some network lag the audio stream would become distorted or the channels out-of-phase. I was able to work around this issue by rewriting the Quisk pulseaudio driver in the asynchronous API. This is the method I am currently using.
RTP: This sends out the data via UDP packets. There is no acknowledgement of packet receipt on the client side, so data will be dropped if the network lags. This mode seemed “glitchy” when I tested it and resulted in lots of audio artifacts, clicks, pops, etc. It was pretty much unusable.
Native Tunnel: This is where an interface on a remote machine appears on the local machine the same as any other pulseaudio source or sink. This is handy because it is transparent to the client program, but in my testing there seemed to be a fair amount of network overhead associated with it. I was finally able to get it working by forcing a maximum buffer size when opening the connections. Otherwise, lag would accumulate to absurd levels to where any action was followed by a 5+ second delay.

Also, you’ll need to add the following line to default.pa as well. Substitute your own network subnet if different from 192.168.0.0./24.

\n\n\n\n\n\n\n\n

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24 auth-anonymous=1

Modify /etc/pulse/default.conf on the rpi for the wolfson card. This is what I’m using. The default-fragmets and default-fragment-size-msec were determined experimentally. These values seem to work well without taxing the rpi CPU too much. Other values were left default.

\n\n\n\n\n\n\n\n

allow-exit=no

high-priority = yes

nice-level = -11

realtime-scheduling = yes

realtime-priority = 5

exit-idle-time = -1

default-sample-rate = 96000

alternate-sample-rate = 48000

default-fragments = 4

default-fragment-size-msec = 80

Finally, to add real-time priority for pulseaudio on the pi, modify /etc/security/limits.conf. Add the following lines and ensure whatever user you want to run pulseaudio as is in the audio group.

\n\n\n\n\n\n\n\n

@audio - nice -11

@audio - rtprio 9

After all these changes, you’ll need to restart pulseaudio on the rpi (and your local machine if you used paprefs to enable native sharing.

7) Compile and install usbsoftrock. Download the source from the link below. Untar it, do a ./configure, make, make install. You’ll need to apt-get libusb-dev and libncurses5-dev or the configure step will fail. https://code.google.com/p/usbsoftrock/downloads/list After it’s installed, you can run it in interactive mode or with “-d” for it to listen on the network. I run it as sudo with the -d switch so that quisk can talk to it remotely via UDP. Put an “&” after the command to send it to the background.

8) Modify wolfson volume settings. I created the following script based on the “use scripts” that wolfson provides with the kernel source code. Name it something like SDR-volume.sh in your home directory.

\n\n\n\n\n\n\n\n

#!/bin/bash

amixer -Dhw:0 cset name='IN3L Volume' 8

amixer -Dhw:0 cset name='IN3R Volume' 8

amixer -Dhw:0 cset name='IN3 High Performance Switch' on

amixer -Dhw:0 cset name='IN3L Digital Volume' 128

amixer -Dhw:0 cset name='IN3R Digital Volume' 128

amixer -Dhw:0 cset name='AIF1TX1 Input 1' IN3L

amixer -Dhw:0 cset name='AIF1TX1 Input 1 Volume' 32

amixer -Dhw:0 cset name='AIF1TX2 Input 1' IN3R

amixer -Dhw:0 cset name='AIF1TX2 Input 1 Volume' 32

amixer -Dhw:0 cset name='HPOUT2 Digital Switch' on

amixer -Dhw:0 cset name='HPOUT2L Input 1' AIF1RX1

amixer -Dhw:0 cset name='HPOUT2L Input 1 Volume' 32

amixer -Dhw:0 cset name='HPOUT2R Input 1' AIF1RX2

amixer -Dhw:0 cset name='HPOUT2R Input 1 Volume' 32

At this point, the pi should be configured. I need to go back and make a few scripts to automate things, but right now I manually start pulseaudio, usbsoftrock and run the SDR-volume.sh script anytime I reboot.

9) We need to download Quisk on our local machine. If you are running a 64 bit machine, you’ll need to compile it. Once you download and unzip (or git) the source, simply type “make” in the directory and then things will start compiling. See the link below to help identify the necessary libraries. http://james.ahlstrom.name/quisk/docs.html#Installation

10) Finally, you will need to create a ~.quisk_conf.py file. This overrides the defaults in the Quisk directory. Change the name of the sound devices to match your setup. When in doubt, use “pacmd list-sinks” or “pacmd list-sources” to find your hardware. You’ll need to change the ip address for IQ_Server_IP to match that of the raspberry pi.

\n\n\n\n\n\n\n\n

name_of_sound_capt=\"pulse:alsa_input.platform-snd-rpi-wsp.0.analog-stereo\"

name_of_sound_play=\"pulse:Channel_1__Channel_2.2\"

channel_i=1

channel_q=0

sample_rate=96000 #I/Q in

playback_rate=48000 #audio out

name_of_mic_play=\"pulse:alsa_output.platform-snd-rpi-wsp.0.analog-stereo\"

mic_playback_rate = 96000 #I/Q out

mic_play_chan_I = 1

mic_play_chan_Q = 0

mic_out_volume=0.8

digital_input_name = \"pulse:digital-in.monitor\"

from softrock import hardware_net as quisk_hardware

from softrock import widgets_tx as quisk_widgets

usbsr_ip_address = \"192.168.0.6\"

usbsr_port = 19004

latency_millisecs = 300 #was 150

data_poll_usec = 5000 #was 5000

hamlib_port = 4532

show_pulse_audio_devices = False

IQ_Server_IP = \"192.168.0.6\"

","actionData","errors"]

Latest

Vike SSR Rendering

Re-Engineering the OM617 Glow Plug Relay

Using the Raspberry Pi and Wolfson Audio Card as a Remote Softrock Interface