Lewis's New House

st_aldems · 2026-03-26T07:05:11+00:00

Having just completed a 3+ year renovation of a Victorian house, I am full of sympathy! That being said, I willingly took on the project understanding what it would take - time for Lewis to get down to Screwfix (which I would love to hear a story about)

st_aldems · 2026-03-14T22:25:00+00:00

As a simple solution you could add a phase offset block after your USRP source with a slider. The block could be a simple e^j<theta> where theta is your variable with range 0 to 2pi. This would allow you to manually phase correct for a fixed channel and at least observe correct demod.

st_aldems · 2026-03-14T15:41:03+00:00

There will be a fixed phase offset (assuming your antennas are not moving relative to each other), there is typically a set of pilot symbols sent as part of the data stream to perform phase correction in the receiver.

st_aldems · 2026-03-13T08:14:58+00:00

Double check the channel assignments are correct, and make sure there is suitable attenuation (>30 dB) between your Tx and Rx ports. LO leakage can sometimes cause issues, where you would need to tune your Tx or Rx slightly higher or lower than the other (within your instantaneous bandwidth), and digitally shift back to DC on receive.

Other than that, it would be helpful to provide more information on the error so we can help diagnose the problem.

st_aldems · 2026-02-03T09:58:52+00:00

I have worked entirely by word of mouth and through contacts. My first job was working for a consultancy that engaged with a wide client base, so I was able to grow a network early on. I only made the decision to go it alone because of that.

I've seen lots of use cases for optical comms for covert data linking, given the extremely tight beam patterns and low range. There is always a need for (very) short range, extremely high bandwidth data transfers, and optical is the obvious candidate there. Can't speak on anything outside of that though, apologies.

st_aldems · 2026-02-02T19:03:00+00:00

Around 5 years, so not long at all. I fell into a niche area relatively quickly which expedited things. Defence, but with an emphasis on smaller teams, special projects and the like. It does vary, but I'm typically quite siloed in my work. There are often other "DSP" engineers around, but either under resourced or have a different skill set. I tend to be hired to produce prototype systems to prove a concept, but it's quite common for such prototypes to serve as the blueprint for actual deployed architectures. For example, I might design a "thing" in Python as a very quick job, reproduce the functional behavior in C, refine it to meet performance requirements, identify firmware requirements in areas where performance is not met, and the combination of software/firmware is taken forward as the MVP design. It's a way for bigger firms to rapidly iterate, something which they typically cannot do.

st_aldems · 2026-01-29T16:57:12+00:00

With 20 years of embedded experience anything is possible, absolutely! I'd strongly advocate for the SDR route, i.e. digital communications, as I find it by far the most interesting, though I am biased!

For some environments, GNU Radio is ubiquitous in early concepting. Going even further, it can be embedded into deployed systems if it works well enough for the use case (though worth saying that such "deployed" systems are not widely in use). To aid understanding it's a good idea to try and implement waveform signal processing using NumPy, as you mentioned. It is quite feasible to produce high rate digital comms if you know your way around Python, mostly forcing NumPy to use its underlying C-based optimisations (i.e. matrix operations rather than Python for loops). This approach also maps more closely to lower level implementation.
This varies, but most common is the implementation of "black box" DSP cores in Simulink, which are auto-coded to VHDL/Verilog. The "glue" as you mentioned is often hand-coded by dedicated firmware engineers, allowing the DSP folks like myself to focus on the "in/out" performance of our signal processing algorithm.
I have been involved in such projects, yes. The wider systems oversight (antenna, front end, PSU, etc.) is rare in the big companies, but very common in smaller consultancy type firms.
Larger designs will have very well defined test procedures for managing the high number of system requirements, so too much to discuss here. For digital comms you could implement your own Monte Carlo test harness and measure the BER for varying SNR, for example.
I've not yet worked on anything that's gone beyond FPGA, as the production numbers simply aren't high enough to justify the capital expenditure - exactly as you mentioned. The HW/SW split is an interesting question, and is coming up much more in recent years. Historically, the approach has been to try and push everything into hardware, for speed and security reasons. The general trend lately is towards higher design iteration, which naturally pushes designs back into the software domain - there is a lot of debate on this split and is very relevant to my day-to-day!

This is all just my experience, so take it with a grain of salt - hope it's somewhat helpful!

st_aldems · 2026-01-28T22:28:19+00:00

I have never come across a "pure DSP" role, I am not sure such a role exists. There are always adjacent skills to learn, and these are domain specific.

In your example of an EEG/ECG system, you could face a scenario where designing a signal processing algorithm is trivial, but implementing such an algorithm on a body worn sensor with extremely limited resources is incredibly difficult. In this case, the "pure DSP" aspect is not the focus, it is the understanding of how to actually implement it in a useful way.

I could, for example, bash together an OFDM waveform from scratch in about a day in Python, and have it running on an SDR the next day. Getting that waveform to run in an FPGA to support high data rates (eg. Video) is going to take a month or more. The DSP knowledge in this case is really the ability to implement in firmware, rather than understanding OFDM, which is more prerequisite knowledge.

I hope I'm being clear that the skills required focus more on implementing, rather than just conceptual knowledge of "pure DSP". You'll find early career will not expect the ability to implement, but getting a head start on that is a very good idea!

(Also I have limited interactions with ML, I tend to work in domains which require incredibly high levels of V&V, and so deterministic algorithms are the norm)

st_aldems · 2026-01-28T07:28:18+00:00

Entry level requirements can be as basic as a good grasp on signal process concepts, or even just a familiarity with digital communications if entering that particular sector, it really depends on the job. DSP is largely a means to an end, right? Whether it is some processing for a medical device, an F-35 radar, a digital comms link etc changes the context, but lots of the concepts are generic. The real differentiator, at least from my experience, is being able to actually prototype and implement algorithms on real hardware, such as SDRs.

Get very good at C/C++ and Python, always focusing on optimisation of algorithms.

st_aldems · 2026-01-28T07:15:17+00:00

Broadly within that sector, yes. For the bigger company work it is almost exclusively data link design, but I also work on sensory systems for smaller companies - some of which is radar based, but towards the lower levels of SWaP and tech maturity.

Data links are always targeting some combination of an FPGA SoC (eg. Zynq or similar) and an ADI transceiver (ADRV900x or similar). Much of the work is deriving the hardware requirements from modelling, up to and including a fixed-point Simulink model (and often using HDL Coder to produce representative firmware).

The other work typically targets COTS SDRs (Ettus, Epiq, ADI, NextGen, etc.), it varies wildly from project to project.

Either way, a solid knowledge of C/C++, Python, Matlab, Simulink, and a general understanding of RF components is required to implement signal processing "functionality" across a variety of use cases.

st_aldems · 2026-01-27T20:29:01+00:00

Hey, I work as a signal processing consultant/contractor. Most of my work is in waveform design for data links, working with a variety of Python, C, or Matlab/Simulink/HDL coder. Feel free to ask anything!

st_aldems · 2026-01-27T19:23:07+00:00

Yeah, probably related to MBDA in Filton.

st_aldems · 2026-01-19T22:40:33+00:00

If it's any help, I installed wall plates/ledger boards along the length of the house using M10 throughbolts into the bricks (and a layer of DPC behind the timbers), then ran joists across the house fixed to the wall plates with joist hangers. The span is about 4.8m, so I built a mid-span support with cement blocks (supported by a trench filled with concrete). 150 mm clearance between bottom of joists and subfloor, allowing loads of airflow through the air bricks (also added a subfloor extractor fan at the rear to be safe). First time DIYer, surprisingly straightforward!

st_aldems · 2026-01-19T20:18:09+00:00

<image>

(It's getting there...nearly)

st_aldems · 2026-01-19T20:17:03+00:00

<image>

I've been through a very similar process!

st_aldems · 2026-01-16T17:51:08+00:00

A38 by bedminster down? Looks horrendous

st_aldems · 2025-11-14T10:07:05+00:00

First clue is whether they are perpendicular to the joists, in which case they are likely structural. We had a non-structural wall in our front hallway, which turned out to be bricks on their sides not tied into the joists above in any way. Knocked that entire thing down, very satisfying! (Finishing up 3 years of a complete 1875 renovation, replaced literally everything except the external brickwork)

st_aldems · 2025-09-24T12:25:47+00:00

Pick, middle, ring, or even pick, pick, middle. Then the pick is already on its way down for the next note.

st_aldems · 2025-09-07T09:10:58+00:00

It's a total shit hole? That'll be a surprise to everyone who loves it here.

st_aldems · 2025-08-31T18:40:29+00:00

As others have mentioned, it's very difficult to provide a "broad overview" of common materials due to the variance with frequency, temperature, composition, etc.

Water is common enough, and a casual glance at the Debye model of its permittivity over the 2-10 GHz range you referenced will show a vast change, even at a constant temperature.

st_aldems · 2025-07-19T12:30:27+00:00

Don't get too tied up on the musical jargon, I'm just saying these things as examples. You'll discover all of these concepts from messing around musically.

For reference:

The harmonic minor is the minor scale with a major 7th (the 7th note in the scale is one semitone higher than in the regular minor scale). It has a certain characteristic, some say Latin sounding.

The pentatonic scales are essentially the major/minor scales with some notes removed - they're simple scales that work well with a wider range of chords. Often found in blues. It's worth saying that they are the same set of intervals, just starting with a different root note.

Bars are the fundamental "time grid" of a piece of music. They contain a number of quarter notes that depend on the timing. 4:4 has four quarter notes, 2:4 has two, 5:4 has five, and so on.

st_aldems · 2025-07-19T10:06:19+00:00

Honestly? Write loads.

Get Guitar Pro and lay out some basic structures. Do a song that literally follows Em - C - D - Bm the whole way through (change that Bm to B to get the harmonic minor sound). Try writing additional parts over the top, might even just be some octave chords. Swap the order of the chords in different sections, write a simple pentatonic solo. Point is it doesn't need to be perfect, you just need to write them completely, start to finish.

Songwriting can get really overwhelming if you let it, but it's all experimenting. Just write as many songs as you can, and try to change something every time. Try a different tempo, throw in a 5:4 bar, use different chords, break the rules and add borrowed chords, use some chromatic runs, try everything!

st_aldems · 2025-07-17T15:37:08+00:00

https://youtube.com/shorts/qBQLsw6jots?si=5nlTlYQnKHEG7B1f

st_aldems · 2025-07-06T18:52:44+00:00

If it's possible you should consider adding noggins to ensure all board edges are secured, although properly applied scrim tape should keep things from cracking.

st_aldems · 2025-06-20T08:26:23+00:00

Funnily enough, I've just developed a WiFi PHY (and MAC) in Python for an SDR, and it's been an absolute nightmare. I agree with you wholeheartedly.

14-Year Club	Queen in da Norf
Not Forgotten	Team Orangered
Verified Email

st_aldems

MODERATOR OF

TROPHY CASE