GitHub software contributors "welcome pack" ?

[VK-JOE]

Hello Everyone,

I hope I am not “stepping” on some sensitive issues or being out of line with this post / request.

I would like to make a contribution to this community and want to take a “deep dive” into the existing Thetis software and P2 associated firmware.

I know there is a repository on GitHub, however it is difficult for a newcomer to find some guidelines in deriving a “working set of code” that can be compiled from source with all the required dependencies and compilation platform recommendations.

There are many so called open-source projects on GitHub without the additional information which allows “newbie” contributors to pick-up the code and be able to successfully compile and deploy.

At the same time there are also some open-source projects which have great “entry” documentation – clearly defining all of the required build parameters and tools.

Is there a software contributors “welcome pack” so to speak that helps to get started with the OPENHPSDR project and specifically Thetis and associated firmware?

Some on the things that could be in this “welcome pack” are as follows; -

System architecture block diagram / flowchart

Here you would define the various functional modules and how they are linked to provide the system functionality.

From this visual guide – it would be instantly apparent which modules do what and at the same time any dependencies in relation to the complete system.

Current revision / work in progress / or desire for some novel coding to enhance operation could also be depicted in such a visual guide.

Having such documentation makes the open-source project “inviting” to new contributors – without the need to spend massive amounts of time to try to figure out how everything plays out – and then with guesswork.

One of the classic problems, and probably why there is lacking in such documentation is the fact that most open-source projects have organic lead developers – these people are brilliant and have the ability to visualize everything in their well-connected neural nets (their brains) – having to pause and create a flowchart to depict what’s going on and how it all comes together – is a major distraction for these brilliant coding individuals.
Not only does it slow-down their development (new code and improvements) but can hinder as well because it interrupts their organic way of thinking.

We are all different and operate in different ways.

For me personally, I find it invaluable (when developing software / firmware) to define everything in a functional flowchart.

In the process of doing this, it forces me to recreate all my thinking – in essence do a compilation in my head – forcing any “error messages” to be highlighted as I create the functional flowcharts.

Sometimes a concept seems to pop-up in your head and its easy to just create the code “on the fly” – but at the same time – if you take a moment and explore the concept “on paper” you engage additional thought processes and believe it or not, can make significant enhancement to the on-the-fly coding by simply forcing yourself to do on the spot documentation.

In some of my software development projects (paid work) I spend at least 70%+ of the entire project time on documentation system flowcharting before writing any code.

Code creation becomes easy using this approach.

Other developers in the group can “pick-up” and at the same time “hand-over” functional modules with higher success.

This methodology is invaluable when working in a group environment.

Open-source projects are also group environments – but sometimes we don’t have a big group, just a handful of organic coders that simply create excellent code on-the-fly.

After a while each member simply knows the “state of the system” and makes appropriate enhancements as required.

Imposing design / documentation procedures on these individuals can be destructive at times because it stifles their organic working mode.
There are always compromises which have to be made.

But, for what its worth, it would be great to have a more friendly documentation system to help welcome newcomers into the coding realm.
Perhaps this already exists somewhere in this community with Thetis and the associated Firmware and I simply have not come across it??

There is also the scale factor problem – if there is only one or two lead developers – it simply hampers their efficiency in spending time creating “welcome packs” for newcomers, but at the same time it dampens the desire for newcomers to enter the fold.

This is a fine line.

Making it easy for others to “enter” the coding group would bring new life and possibly make it easier – in the long term – for the existing coders and the community?

Some of the things that would assist are; -

IDE platforms for Thetis coding – visual studio most likely – but which version / any dependencies in the IDE or official recommendation?

IDE platform for FPGA – Quartus?

Compilation environment

Dependencies

System / modules flowcharts

Identify – work in progress – what’s the things that need to be enhanced / fixed / improved

Code-set / environment for a successful compilation of Thetis and firmware

Definition and any “heads-up” on the revision system – to ensure latest code is in play

Definition and any “heads-up” on code testing process – when and how it becomes fit for general release to community.



I am sure there are many more questions / suggestions – but these are the immediate ones that come to mind.

Sorry to anyone who might find this post “out of line” – that was not the purpose, I am simply trying to get to speed quickly and thought I should share some of the thoughts I had during this process.

[Trucker]

I wouldn't call your post out of line at all. I think the hard part would be finding someone that can do what you suggest and has the time to implement it. I have dabbled in coding as a hobbiest off and on for years. Beginning with Basic ( various flavors) C, C++ and finally C#. The reason I ended up trying to learn C# is because I bought into the Flex 6000 series radios and since they made a very nice set of API's available allowing those that are interested the ability to create their own interface to the radio's. While my attempts haven't been the best,I consider it a learning experience.
I have downloaded the source code for Thetis. But, just like you, I am not sure what dependencies are needed to successfully build the project. I haven't tried asking for more information yet as other things have come up that need my attention more.
It's not that I think I can add anything of value to an already excellent program. But, it would be interesting to better understand the inner working of Thetis.
James
WD5GWY

[w-u-2-o]

Dare to dream!

There is little to no material or documentation like you are looking for. Unless you develop it yourself the likelihood of there being any is close to zero.

In addition, modern, cooperative software development practices have never been used in the openHPSDR community. While you'll find Github repositories, they are merely resting places for source code and have never been used in any significant way to assist with development.

openHPSDR development has never been like more mainstream open source developments. There have been very, very few people who have made significant or major contributions since the inception of the project. And none of these folks have brought any modern software development practices to bear on the problem, probably because most of them are hobbyist developers by nature with little to no professional software development background. Or their professional software development background is from a previous age where modern tools, development processes and techniques were unknown. They generally run as solo operations, and the few tidbits that trickle in from other contributors get incorporated manually rather than by means of any modern, automated software development tools.

The UI code is a train wreck of epic proportions by any modern standard. It was already that way as an outcome of the old, first generation Flex radios it was used with when it was adapted for use by the openHPSDR project. A certain amount of software refactoring and rearchitecting took place that resulted in Thetis, whereby a large portion of the DSP content was pulled out into a single DLL, channelmaster.dll. This, along with the pre-existing wdsp.dll, forms the bulk of the DSP functionality in Thetis. Richie, MW0LGE, has been the most recent major contributor, concentrating primarily on the UI, including a major rewrite of the spectral display code to use DirectX. But the UI still remains a nasty plate of spaghetti code. Richie and others have often said that it would be easier to start from scratch than fix the existing UI.

The historical code repository for openHPSDR has been https://github.com/TAPR If you look through that carefully you will find documentation on the software-firmware API (so-called Protocol 1 and Protocol 2), and some documentation on the WDSP library. Unfortunately there is no equivalent documentation for channelmaster.

But that is just a starting point. The version of Thetis that is currently most prevalent can be found here: https://github.com/ramdor/Thetis-2.9.0

As for learning how to build Thetis in Visual Studio, there are quite a few folks right here on this forum who can guide you. For example, see viewtopic.php?f=9&t=4339

[Trucker]

Thank you Scott. I had forgotten about that particular thread. I did have intentions of contacting Joe and asking some questions. But, old age and wife related projects side tracked that process. And I forgot all about it.
James
WD5GWY

[laurencebarker]

Your post isn't out of line in any respect!

I'll chip in a little here if I may, as someone who has contributed a little to Thetis. (Although if you don't use Andromeda, you may never find it!)

Some of your questions can be answered. For example Thetis is built entirely using visual studio community edition, and I believe the most recent release in use for the project is Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.1.1. It should be a case of download studio, use a git client to download a copy of the source, and press "build". It's been that simple for me before.

You can run git from inside studio. I use "github desktop" which for my limited use of git works fine.

The FPGA code is built using quartus, and Rick may be able to tell us which version. I know that not all of the code is in a single github repository: a few verilog modules need to be pulled from other locations.

The current github repository for Thetis is more of a holding place at the end of major revisions. Someone takes a copy and works on it, and puts it back at the end. That's fine if only one person is active at a time; it has also once meant that code I'd completed couldn't be put into the code base for 11 months. The alternative, however, is that all the developers know how to use github co-operatively. That would require knowledge of how to use branches and merging properly. I'm entirely an amateur developer and I don't know how to do that; maybe everyone else is better skilled!

What we don't have at the moment is a well maintained bug list or new feature list that other developers could dip into. Something that could progress from "there is this issue" to "here is a proposal for changes that would be needed to fix it" to "here is a candidate solution" would be useful I suspect. I know professional software teams use Jira for that; again I'm not a proper developer and I've never personally used it. I've seen it used and I don't think it is hard, but it may incur costs.

I agree that documentation is sparse. There is documentation for channelmaster, but it is draft. We could ask if it could be released "as is".

There is also an out-of-date manual for Thetis: I wrote it a while ago, before one of Richie's mega improvement phases and much of the content rapidly became out of date. That could be taken on by someone of they can keep up with changes.

I agree with Scott's observations about the UI. There is no separation between the visual components that form the UI, and the business logic that takes UI changes and works out what the DSP needs to do; and for data coming back from the DSP, that makes the necessary changes to UI settings. If you want to change frequency today, you convert the frequency you want in Hz from an integer to an ASCII string, copy that string into a text box on the UI then call its "lost focus" method. That can't be right! Some stuff is in UI methods; some is in properties; some is in-line coded. Ideally the CAT code and UI code could interact entirely with properties, but today that's not possible. A pre-requisite to major UI change would be to achieve complete separation; then we could have the current expanded and collapsed views as entirely separate UIs, and people could develop others rather than having to put everything into one. I reckoned achieving that was 5 person years' work, which may be why it hasn't happened. It is very suitable for a team, if assisted by documentation though! It could also be done incrementally, possibly using the CAT commands to establish an updated property model them moving the UI across to that later.

[DL2XY]

...
If you want to change frequency today, you convert the frequency you want in Hz from an integer to an ASCII string, copy that string into a text box on the UI then call its "lost focus" method. That can't be right! Some stuff is in UI methods; some is in properties; some is in-line coded.
...

You don't have to use such a complicated way to change frequency. There is a public property named "public double VFOAFreq" in console.cs.
It is referenced nearly 200 times in the source. It has been there since FLEX-times.

But you are right, without proper documentation you have to find it first among 50K+ lines of source, which is prone to error.
For a simple change in UI i normally need about an hour average, 20 min to find the right code, 30 min to check for side effects, 5 min to change and 5 min to test. Quite inefficient ...

Dont give up,
Walter

[laurencebarker]

Hi Walter

yes you are quite right, and when I look at the Andromeda code it does actually use the property. I apologise on that one!

But look 20 lines down and see how that property changes frequency... it writes ASCII text into a UI box and call the lostfocus method. The "business logic" is in the UI control, instead of a function ChangeVFOAFrequency() or something similar. So to change the UI completely, there is still a way to go!

[DL2XY]

Ok, i see...

And the 720 lines of "txtVFOAFreq_LostFocus"...

Hope i never have to work on this part.

[W4WMT]

Unfortunately there is no equivalent documentation for channelmaster.

Aha, actually there is

ChannelMaster Guide.pdf

(424.66 KiB) Downloaded 713 times

Unfortunately, it was never uploaded into the appropriate place within the GitHub/TAPR tree. I don't even know who has upload privileges, to ask that it be included.

One caveat: During the Thetis v2.9.0.x rollout, Warren & Richie made some minor changes to a couple of the exported functions that support a few UI niceties in the PSDR console project. I will reach out to Warren to see if he's had a chance to update the guide.

73, Bryan

[VK-JOE]

Its good to hear such a varied but positive response – it demonstrates that there is still a strong community here wishing to have what we all desire – a great software platform rich in features which are well documented and most importantly having a healthy and growing number of individuals contributing to its development.

Its not easy to get on the “right track” of documentation and development maintenance offered by GitHub.

Like stated – not everyone knows their way around GitHub, and if you are a coder – your focus is on the coding, rather than spend hours / possibly days, in getting super competent with the GitHub platform.

What would be nice is to identify those in this community who would like to contribute in the software development.

I guess there are various skill sets, some excellent coders, others possibly good system designers familiar with various DSP processes, and maybe more of you who are GUI gurus – all in all I would expect a varied skillset which we should – with all of you willing – harness to the benefits of this OpenHPSDR community.

What would be great, if possible, is to identify those who are experts with managing projects with the GitHub platform – or other “open” development repositories / platforms.

The idea is to take the “strain” and simply make it easier for the core developers / coders here – to improve on the documentation and management of the code being generated.

If there is a “parallel” group – don’t need to be a coder – to in effect be a “personal assistant” to the coder – this person / group would do all of the repository interfacing and managing of the code for the coder – whilst having a special relationship with the coder – to collect and offload their work into the appropriate repositories once signed-off by them.

It’s just an idea, and if it can be made to work, would help the coders get good documentation and offloading to the repositories – for others to pick-up and develop further.

I feel that rather than put pressure on the existing coders to spend more effort in mastering GitHub – their time is better utilized in the writing of the code – but other skilled individuals can do the GitHub work for them on a one-to-one basis.

If this works – it can only help in the short term.

For the long term, it would be great to once again identify a group within the community who could / would be willing to be part of a massive effort in complete system functionality (even to the level of state machine) documentation.

The idea here is that with this level of documentation on the existing software / firmware functionality, we could start a “parallel” group of coders / system designers – to rewrite the software using modern development tools and techniques – to implement a functional equivalent to existing Thetis and the associated firmware.

This will open a new door, and when complete (or should I say if completed) would be a new start for multi-OS support and ease of development so newbie developers would find it easy to enter and help in this community development.

The advantages are numerous, the new code could be modular (no more spaghetti which is common in organic development – where one developer had to pick-up from poorly documented code produced by a developer who is no longer with us or interested in this project).

Apache-labs can finally move on to new H/W and not be constantly chasing replacement components for EOL devices – in particular the FPGAs.

This does not mean that the EXISTING Anan H/W which all of you already have will be no longer supported, to the contrary, if the new modular code is developed, it will be relatively easy to have a “compatibility module” which will implement the functionality on the Old H/W – but obviously on what the old H/W can physically support.

It would be stupid, to restrict new functionality from the new H/W hopefully the likes of Apache-Labs would build, but at the same time – older H/W can be supported.

It’s like having an Anan 100D – sure it works with the Tehtis software – but some functions are missing compared to a ANAN-7000DLE MKII, etc., etc.

Is all of this wishful thinking?

Maybe, I don’t know.

But I will definitely try to get this going.

I have a colleague who is now a Dean of Electronic Engineering in a prominent University.

Can reach out and interest him is getting some support.

The best outcome I would see is as follows; -

He reaches out to one of his colleagues – Dean of Computer Science – and interests him in a major student project over several years – structured (no one person) – to investigate and perform a major software redesign from an existing code base with average documentation, to one of “State-of-art” utilizing the most advanced design tools and techniques – creating a modular software / firmware system for existing and future OpenHDSDR hardware / systems.

What’s in it for the Dean and the University?

To demonstrate the modern teachings and techniques and how advanced students in their respective years / departments created a community development software codebase / development system for others to adopt in future community software development – not only for open source (Free) projects – but also for commercial (paid) software development.

This would be an accolade for the university department of computer science – which often looks for worthy projects to undertake for their advanced students / researchers and PHD candidates.

It could be a win-win for everyone involved.

Obviously, this would be a parallel project – no intention to ditch the existing development work with Thetis.

If its successful, then there will be an opportunity to start using the new software platform and the community will decide which system will progress into the future.

If there are other members here who have links / personal relationships with individuals that could deploy some “human” effort in getting something off the ground (as suggested above – or better) it would be great to share with us all.

As a final note – a “on air” colleague has made available to me an Anan 100D (early version – gray case) for an extended “loan” – so I finally have some H/W to play with.

When I get some time – will get into giving Thetis a good “run”.

The way I see it, coming from non-Anan platforms – I can be quite critical and perhaps “see” things most individuals using the Anan radios daily might miss.

Its all good and this is certainly a great hobby - as we explore new rabbit holes – hopefully the outcome will be beneficial not only to ourself but the OpenHPSDR community as well.

[w-u-2-o]

Unfortunately there is no equivalent documentation for channelmaster.

Aha, actually there is

ChannelMaster Guide.pdf

Unfortunately, it was never uploaded into the appropriate place within the GitHub/TAPR tree. I don't even know who has upload privileges, to ask that it be included.

One caveat: During the Thetis v2.9.0.x rollout, Warren & Richie made some minor changes to a couple of the exported functions that support a few UI niceties in the PSDR console project. I will reach out to Warren to see if he's had a chance to update the guide.

73, Bryan

Thanks, Brian!

[w-u-2-o]

Its good to hear such a varied but positive response – it demonstrates that there is still a strong community here wishing to have what we all desire – a great software platform rich in features which are well documented and most importantly having a healthy and growing number of individuals contributing to its development.

Wishing is not the same as having. There have been very few, VERY few people interested in contributing in significant or substantial ways. The reasons for this are many, more on this below.

Here's some perspective from someone who just retired after four decades in the high tech industry, the last twenty as chief engineer and system architect, designing and managing projects involving 10 to 100 engineers of all disciplines.

Its not easy to get on the “right track” of documentation and development maintenance offered by GitHub.

Like stated – not everyone knows their way around GitHub, and if you are a coder – your focus is on the coding, rather than spend hours / possibly days, in getting super competent with the GitHub platform.

This is entirely wrong. GitHub is among the best code management systems out there, and has developed a massive following because it makes development easier, not harder. With apologies to our esteemed openHPSDR developers who have generally eschewed code management systems, any serious developer will know how to use GitHub at least at the most basic level, and any professional developer that works on a code development team will absolutely be fluent in a tool like this and many other tools. GitHub is merely the tip of the iceberg. Project management tool suites such as those provided by Atlassian dominate the professional development world.

If there is a “parallel” group – don’t need to be a coder – to in effect be a “personal assistant” to the coder – this person / group would do all of the repository interfacing and managing of the code for the coder – whilst having a special relationship with the coder – to collect and offload their work into the appropriate repositories once signed-off by them.

It doesn't work like that. Code management and repository tools like GitHub are as basic as a shovel is to ditch digging. If they are to be used then they necessarily become part of the minute-to-minute coding process. What you describe is what we have now: people coding in their own little vacuum, manually integrating other folk's contributions, then throwing the entire mess over the wall into GitHub occasionally. That's not what GitHub is for.

It’s just an idea, and if it can be made to work, would help the coders get good documentation and offloading to the repositories – for others to pick-up and develop further.

Again, it doesn't work that way. You can't document other people's work. You can clean up the documentation, you can write top level specifications, but the coders are the ones who document what they do.

For the long term, it would be great to once again identify a group within the community who could / would be willing to be part of a massive effort in complete system functionality (even to the level of state machine) documentation.

The idea here is that with this level of documentation on the existing software / firmware functionality, we could start a “parallel” group of coders / system designers – to rewrite the software using modern development tools and techniques – to implement a functional equivalent to existing Thetis and the associated firmware.

This will open a new door, and when complete (or should I say if completed) would be a new start for multi-OS support and ease of development so newbie developers would find it easy to enter and help in this community development.

The advantages are numerous, the new code could be modular (no more spaghetti which is common in organic development – where one developer had to pick-up from poorly documented code produced by a developer who is no longer with us or interested in this project).

You state the obvious. The problem is that if anyone was interested in doing this they'd be doing it.

What you describe is a large effort. Clearly there are many other large, highly successful, open source efforts that exist. Efforts where many hundreds of developers make contributions every day, thereby leading to continual and significant improvement.

The very reason those large, highly successful, open source efforts exist is because they attract a huge following of users, a large fraction of whom have significant, professional coding experience. This environment does not exist for openHPSDR. Consider that there are probably far less than 10,000 ANAN units of all types that have ever been produced. Maybe there are 500 ANAN owners who might be software professionals. Maybe 50 of those have given any consideration at all to contributing. Over the years only a very few have ever acted on that impulse. Typically there is only one significant contributor at a time, and they will typically contribute for well under a year before burning out.

In the seven years I've been part of the community I can only think of a very few people who have made significant contributions to PowerSDR and Thetis. The first are the original core team of Phil, Joe, Warren and Doug. There may have been others but that was before my time. Later we had a lot of work done on CW and VAC by Chris and Bryan, along with Doug and Warren. Then there was Warren's work on PureSignal 2.0 and the audio chain. More recently we've had Richie working on the UI and control functionality. If I've forgotten anyone please make the necessary additions/corrections.

That is not a lot of people considering the depth and complexity of the resulting product.

The other thing to understand is the motivation in this sort of development space is very, very different. Nobody is about making a lot of money. It's hobby time, for the love of the hobby, and people did what they did and do what they do only to get features and functionality they were passionate about. They did or do the minimum necessary, either to prove it could be done, or to just get it working so that they could enjoy it themselves.

Indeed, the entire Thetis/Apache ecosystem that exists today essentially is a hobby time thing that became bigger than that, but never really launched into a full-fledged commercial product space. I wasn't in the community when it happened, but when the openHPSDR hardware design finally iterated into something that involved a BGA FPGA package, something that is hard to solder reflow in a toaster oven in your kitchen, Apache stepped in with an offer to supply Hermes boards to the hobbyist community. Things spiraled from there, but never quite achieved a full-on, professional level of product development. Nevertheless the product, hardware, software and firmware, is good enough that it has the flavor of it, but it's not like buying radios from Flex, Expert, Icom, etc.

Apache-labs can finally move on to new H/W and not be constantly chasing replacement components for EOL devices – in particular the FPGAs.

The state of the software and firmware is absolutely not holding Apache back from doing a new design in any way.

Apache can totally spin a completely new board tomorrow. They could hire a firmware engineer and port the firmware onto any device they want. They are simply not motivated to do so. There is no need for them to do so. Apache could be selling many times the number of units they sell today if they wanted to. Clearly they are happy with the level of business they have.

Is all of this wishful thinking?

Pretty much

The thing is, all of the hardware, software and firmware are based on open source licenses. The derivative works clause in the license requires that those who use the core elements of the prior work, e.g. channelmaster, WDSP, etc., have to maintain it as open source. For instance, this is why Apache will provide you with schematics. There are limits. Apache won't provide you with PCB Gerber files because that's not part of the licensing agreement.

So what does that mean? That means that anyone, ANYONE, could start a company tomorrow that built, for profit, openHPSDR radio systems. They could hire professional hardware, software, and firmware developers and produce any sort of improved, modern designs they want. As long as the schematics and source code are published it's all good. I think that only hardware can be sold at a profit, not software or firmware, but that's a minor nit.

He reaches out to one of his colleagues – Dean of Computer Science – and interests him in a major student project over several years – structured (no one person) – to investigate and perform a major software redesign from an existing code base with average documentation, to one of “State-of-art” utilizing the most advanced design tools and techniques – creating a modular software / firmware system for existing and future OpenHDSDR hardware / systems.

What’s in it for the Dean and the University?

To demonstrate the modern teachings and techniques and how advanced students in their respective years / departments created a community development software codebase / development system for others to adopt in future community software development – not only for open source (Free) projects – but also for commercial (paid) software development.

This would be an accolade for the university department of computer science – which often looks for worthy projects to undertake for their advanced students / researchers and PHD candidates.

It could be a win-win for everyone involved.

That's a hugely interesting idea. If you can develop any traction on it I'd love to be a technical advisor

[K1LSB]

Joe,

I'm seeing a potential for problems / pitfalls with the thought of having a university doing any open source modifying of an already-established piece of software.

Generally speaking, universities are for-profit institutions and the dollar sign is at the forefront of nearly everything they do. In particular I'm remembering the example of UCSD Pascal, a programming language developed by the University of California at San Diego for use by the student body. It became a popular programming environment for worldwide use and was licensed by UCLA. They didn't give it away for free.

With that said, if you feel like trying to convince the Dean of Engineering at a prominent university to give away the fruits of his department's labor for free, please do so!

Mark

[W2PA]

As a past and (hopefully) future developer I thought I'd chime in very briefly.

VK-Joe - the spirit of what you wrote is laudable - good job of laying it out. But Scott has accurately explained the reality of our development environment.

Far from being hopeless, though, I think the sweet-spot middle ground would be for us to adopt the basic git process for managing enhancements. This would work even for a loosely organized bunch like us. Scott - you implied as much in your response and I agree. This doesn't have to be heavy weight to get a whole lot better.

[VK-JOE]

@ w-u-2-o
Scott, thanks for your detailed response.

Like you said wishing is not same as having, but you should not give up hope.

You are probably one of the most knowledgeable people in this forum with respect to everything related to OpenHPSDR, the Anan radios and associated software / firmware.

Your feedback is very valuable – and from your comments you might have hit the nail on the head in judging the correct sentiment and the plausibility of getting a new, proactive group of developers, to assist existing key people in the continuing development of these bellowed radios.

However, you should not simply accept the inevitable.

As a newbie to this community, I value any comments and wisdom shared.

But despite of the negatives, you never know - there might be other newbies like me who over time could get things moving – either directly or indirectly.

I welcome the learning process myself and I am sure there are others who feel same.

Sometimes going on the “journey” is part of the learning process.

In this process you might discover something that others overlooked, or simply at the time of their journey, it might not have been possible or effective to realize.

We can only try, and if in the process there is some traction with other like-minded individuals, then it becomes a win-win for the entire community.

Scott, I am yet to meet up with my colleague (the Dean) – as you can imagine he is quite busy and most recently caught covid.

He is recovering, but it’s a slow process.

Hopefully we can catch up soon.

You would be a great “technical advisor” - noted



@K1LSB
Mark, your comments on the potential problems and pitfalls of universities when it comes to opensource projects, is noted.

I have some interesting stories (from my time) where some senior lecturers literally “stole-in-full” some of their PhD student’s projects to realize them commercially.

In the end these failed for the people involved – perhaps just Karma at its best.

I know that my colleague (the Dean) is well aware of this – and if anything does happen – something to mitigate any problems would most likely be put in place before anything happens.


@W2PA
Chris, thank you for your kind comments.

I share your sentiment.

Even if there are not enough potential developers here to create “critical mass” – this should not stop those who – even in their limited way - want to make a contribution and even in the smallest way improve the current situation.

I welcome the opportunity if such a group could be formed.

Perhaps, Scott could create a special forum section for this??

We could have some “sticky” posts – to define some goals and how to slowly work towards them.

Those willing to chime-in and who have some skill-sets could make their contributions.

Eventually there could be some structure and some positive things created to help existing developers and at the same time encourage others to do same.

For the record, it was on 4th September 2022 that I went down the DPD rabbit hole.

Before this time, I simply was interested in getting an Anan radio (any type) to experiment with the software and in the process, have some first-hand “knowledge” in its operation, so when in a QSOs with my friends who do have Anan radios, I could make some useful contributions.

It’s been just over one month since then.

A relatively short time.

During this time, I have researched lots and lots on DPD and associated developments.

This made me more eager to go deeper into this rabbit hole – especially into the OpenHPSDR community and the existing work by Warren Prat with PS2.

I am slowly discovering more and more.

As I go through this journey, I like to share my findings – but to many of you here especially those very knowledgeable like Scott, what I post here is unfortunately nothing new (apologies) – but nevertheless exciting for me and maybe someone else who reads it.

I am still very keen to start going through the Thetis code – to get better understanding and in the process possibly start documenting it in my own way – something I like doing

At the moment I have been very fortunate in receiving a “loan” Anan 100D.

However, I am mindful that sooner or later I would need to get my own radio – which would be my development platform, especially if I get serious with the software development and I don’t see why I would not.

Just a quick comment on the 100D – running the latest Thetis (P2) – I just realized how brilliant NR2 is

DSP noise reduction was one of my old rabbit holes.

I had some experimentation ideas – for a good noise reduction system.

Looks like whoever devised NR2 struck gold - well more than that – they not only had the correct algorithms – but they implemented it also – PROPS to whoever did this!

Yet another reason for wanting some good documentation – so we can see what is actually happening in the various software system modules such as NR2 noise reduction.

If we know and share with others, we can only create better versions in the future, with possible suggestions from a wider community group.

Anyway, I hope other newbies to this community are equally inspired like myself

[w-u-2-o]

Perhaps, Scott could create a special forum section for this??

We could have some “sticky” posts – to define some goals and how to slowly work towards them.

Those willing to chime-in and who have some skill-sets could make their contributions.

Eventually there could be some structure and some positive things created to help existing developers and at the same time encourage others to do same.

We've had more than one "dreamer" or "wish list" topic on the forum at one time or another. They have so far not attracted any developers.

If there ever is a time when more than a couple of serious, active developers decide to contribute simultaneously, they, along with any "dabblers", will be much better served by using the collaboration tools that Github provides. Unlike a forum such as this one, Github is specifically designed to facilitate the communications necessary for efficient and effective software development.

During this time, I have researched lots and lots on DPD and associated developments.

...

DSP noise reduction was one of my old rabbit holes.

I had some experimentation ideas – for a good noise reduction system.

Looks like whoever devised NR2 struck gold - well more than that – they not only had the correct algorithms – but they implemented it also – PROPS to whoever did this!

Yet another reason for wanting some good documentation – so we can see what is actually happening in the various software system modules such as NR2 noise reduction.

You need to climb out of your rabbit holes and start reading the more mundane stuff. If you had even so much as skimmed all of tacked/sticky posts in this forum, something that wouldn't even take you an hour for all of them, you would know who is responsible for NR2, and PureSignal, indeed the bulk of the DSP that we use in our radios. You would have found references to videos and scientific papers. You would have found out that none of this stuff is new, none of it needed invention. The innovative part was making it available in an amateur radio, something previously unheard of outside the realm of professional and military communications.

Here's a homework assignment for you: skim, skim, all the tacked posts in all the sub-forums, no matter how boring or uninteresting one might seem. Do NOT stop to read any papers, follow any links, watch any videos, or go down any rabbit holes. When you finish the last tacked post, only then circle back to do a deeper dive on the ones that are more interesting.

[VK-JOE]

Here's a homework assignment for you: skim, skim, all the tacked posts in all the sub-forums, no matter how boring or uninteresting one might seem. Do NOT stop to read any papers, follow any links, watch any videos, or go down any rabbit holes. When you finish the last tacked post, only then circle back to do a deeper dive on the ones that are more interesting.

I beat you too it ... already started reading ... but thanks for your suggestion.

I have a quick question for you Scott ...

Do you still have the 100D? - I have been using the "loan" 100D I have - I can’t fault it - has very sensitive receiver - is there a review somewhere on the improvements in "performance” a 7000DLE MK II has over the 100D? - ignoring ascetics and jumper conveniences of cause.

Anyway – yes you can pick-up lots of information by simply reading every post that meets your attention - I was a slow starter with this unfortunately.

Cheers

[VK-JOE]

A final question that someone might be able to help with -

I started looking at the - randor/Thetis-2.9.0 GitHub source - and fired-up Visual studio 2022 community edition - but unfortunately, I could not find Version 17.1.1 - which I believe Richie still uses to manage the code.

I could not get a "clean" build - as it flags some dependencies relating to the 17.1.1 version.

Rather than start patching various dependencies - it would be much easier to simply use the SAME Visual Studio environment as Richie.

Does anyone know where you can download the 17.1.1 version?

All the links I find - in the end - pull the latest version from MS

Cheers

[w-u-2-o]

Joe--I moved all your 100D questions to a separate topic: viewtopic.php?f=17&t=4363

Try to keep topics on topic, please! If you have a new, unrelated line of questioning or discussion, search for an existing topic on that subject (there almost always is one) or start a new one in an appropriate sub-forum, please.