I would like to use a P2 as the core of a complete software defined hf transceiver for portable / field use. Much of the basic hardware and software would be the same as for a test instrument. I know it's possible to do, because others have done it with much less cpu. 8 cores means the signal streams, tuning, gui etc can all run in parallel, rather than bumping into each other.
That's a fair way off, like ErNa says, there's a lot of bottom-up 'bios' to develop first.
More random thoughts on oscilloscope-like instruments:-
Oscilloscopes are like motorbikes - the markets for both are very conservative, in that everyone knows what a motorbike should look and sound like. If you gave a modern scope to a time-traveller engineer from the 1940s he would start making measurements almost immediately. The same rotary controls, same functions, admittedly buttons instead of toggle switches, softkeys instead of multiposition switches. I don't know of any make that just uses touch screens - maybe with such a 'hands on' tool they quickly get very greasy.
I remember that the first Hewlett Packard digital oscilloscopes used to stay in the equipment store from one year end to the next, no-one wanted to use the nearly-all-button and one rotary control instruments. Menus within menus - oh dear! Tektronix, LeCroy and so on wisely stayed with something much closer to the traditional look and feel. The HP scopes were slower to use, even when you got familiar.
The little credit card sized instruments radio hams have taken too in big numbers are touch screen controlled by a series of menus. In practice, most folks miss-key a lot of the time using a finger. A stylus becomes almost essential with such tiny selection areas. I have to use glasses to read the screen, which is not the case with my chinese scope. The 8" diagonal screen is easy to read with the naked eye and menus are selected by five horizontal and five vertical buttons that are 'softkeys'. There are no less than 8 rotary controls that do what scopes have always done.
Our 1940s engineer would be amazed at how shallow the case is - no huge crt - and the fact that the instrument isn't a two-man lift, it's a one-finger lift.
Just a little rotary control suggestion - if any are included that is - use knobs with colour coded caps. With controls that serve several purposes, the GUI elements can be colour coded to match the knobs, thus helping the user remember what knob controls what element on screen. (Same idea as scope probes with little coloured bands to tell one from another)
Lots of good observations by bob_g4bby but these also prompt me to ask about the general idea of this CheckMate device.
My understanding is the CheckMate is intended to be more like the Logic Analyzer with some additional DSO like capabilities rather than a full featured DSO (with all these mechanical controls, screen etc.) with a LA capabilities.
Is that so, or am I misinterpreting something ?
I think it's best to clarify that in the beginning. Also the presence (or lack of) screen/mechanical controls should be declared early on, I think. If you ask me, I don't need them on the device despite the fact I very much like the quality mechanical knobs and switches.
We can talk about this till the end of time, better to learn by doing. If I want to show what I want to do the best is to show that it doen't work yet. Someone will jump in and help. We have different choices of hardware: The evaluation board, a starter bundle or even some have a P2D2. Also there are LCD screens around, with or without touch screen. That more or less is all we need to start. I'm currently fighting with SED to understand some of Peter's tricks and find the traps he set up ;-) . My goal is to edit programs in the SD card and so have a self contained system that later will need just a keyboard to modify and test programs in the field. We can fully test ADC and data logging and filtering and... if we remember, that the P2 has independent COGs and can be used as a signal generator, so the signals created are always faster then the acquistion speed and all the developments can be done without external component. If we have them, attaching should not be the problem.
Whatever you say, but my experience tells me if we take that "let's do it and we'll see what comes out of it" approach we might find ourselves with lots of fun while doing "it" but also lots of frustrations with "it" itself later on, if we ever get to the point of finishing whatever that might be.
If we do not define what we are to achieve, we will never know if we have really achieved our goal.
The bigger and more complicated the project is, the higher the chance of failure. And we need this project to be a success.
I just hope the plans that fail are for bad things and these rare ones that succeed are for good things only.
But I'm biased. I used to be a project manager for a major financial institution for many years. Most of the times back then I prayed somebody proved me wrong with my fears, but these prayers were very rarely heard up there in the sky.
Well, any 'scope like' test instrument needs to stream data, display that data in a graph, handle real or virtual buttons, display menus over a live screen - lots of 'bios' facilities to develop without knowing just what the instrument will tune out to be. It might be an idea to standardise on a popular touch display, then everybody can start off with the P2 board they have (I have none yet) and start knocking out these low level features in the software that any instrument would use. Find out what features particularly fits the P2 and the display? This is bottom-up exploration of the concept. I did the same developing an antenna controller last year - just started moving stepper motors and meandered upwards to the final app.
If you plan to succeed then you have succeeded in planning. Good luck to you. As for the rest of us we plan to have lots of fun and if nothing works out then we would have had lots of fun.
The "fun" factor is what gets the creative juices going and pushes us beyond what we would normally stop pushing at. The whole process is a learning experience and that experience is continually built upon to go to the next level. So what if the first design, does A B C but not X Y Z? .... yet.
For those who desire lots of colored knobs, then you can have them. Just want a touch screen? Then you can have it. Some might like a command line interface where they can conjure up all kinds of tricks with quick n dirty one-liners. They can have it.
All these ideas are great and grand ideas and should be declared "impossible" just so that we can then focus on proving otherwise.
I'm starting to get a bit excited about this project. Are you?
What I really like and appreciate is that you speak your mind no matter what others might think of it. And so do I. And i do not see a reason why that should ever change.
Point, shoot, bull's eye.
And NO, I am not starting to be excited about this project. I have been REALLY excited about it even before this thread started. And I NEED this nifty tool too so YES, I'm in for the fun .
The software teams at my last workplace used the 'Scrum' method of managing collaboration on a project - I'm not suggesting such formalism, but the themes are interesting:-
The Agile methodology was developed as a response to growing frustrations with Waterfall and other highly structured, inflexible methodologies. This approach is designed to accommodate change and the need to produce software faster.
Agile values individuals and their relationships and interactions over tools; it features customer collaboration throughout the development process; it responds to change instead of following a set-in-stone plan; and it focuses on presenting working software, rather than documentation.
Unlike Waterfall, Agile is well equipped to handle the complexity and variability involved in development projects.Using the Agile approach, teams develop in short sprints or iterations, each of which includes a defined duration and list of deliverables, but in no particular order. During sprints, teams work towards the goal of delivering working software (or some other tangible, testable output).
Agile is collaboration-heavy, focusing on team strengths and efficiency, along with internal feedback from various departments and clients. Client satisfaction is the highest priority with the Agile approach, which teams achieve by continuously delivering working, tested, prioritized features.
Another way to implement the Agile approach, Scrum borrows from Agile’s foundational beliefs and philosophy that teams and developers should collaborate heavily and daily.
With Scrum, software is developed using an iterative approach in which the team is front and center—experienced and disciplined workers on smaller teams might find the most success with this method, as it requires self-organization and self-management.
Team members break down end goals into smaller goals at the beginning and work through them using fixed-length iterations—or sprints—to build software and showcase it often (which usually last two weeks). Meetings play an important role in the Scrum approach, and during each sprint, daily planning meetings and demos take place to follow progress and gather feedback. This incremental method promotes quick changes and development and adds value to complex projects. Scrum incorporates the structure and discipline of more traditional software development methodologies with the flexibility and iterative practices of modern Agile.
I remember the application under development was maintained in a state that would run at any time during the project (however incomplete). That's a lot like many open source ham radio projects that slowly evolve from a basic working receiver, to transceiver, to transceiver with lots of bells and whistles.
Methodologies and individual needs/wants aside, can we possibly start with establishing the minimum hardware base for what will eventually constitute a CheckMate ?
All options are on the table and I will take a NO as a valid answer too.
Generally speaking, I think I can guess what you mean but that is not what I had hoped for. I dare to say that this is too minimal but my skills and experiences are limited.
I admire your bravery but struggle hard to say no more.
I want to show a simple example: In my garden there is a little well. I want to log continuously the water flow. The source of the water is rain and ground water and the goal is to determine the contributions of the two sources. There is a level detector in the well, a pump, a meter to measure the outflow, a meter to measure the rainfall. So the task is quite simple: the input of the level sensor switches the pump, the ticks from the meters are to log. In the end I know how quickly the well reacts on rainfall (water entering the well directly) and how much water goes to the ground water and then to the well. There have to be some filter operations and correlations. This setup can be realized with a few digital I/Os, need some counting and is a good exercise to test the EDF. And to see how to do such a job in forth using TAQOZ. If you like you can measure blood pressure, your breath, heart beat, sleep quality... Add a microphone to find out if you snore really or if that is only hearsay ;-)
If this task looks to simple: it's the first step to a global network of sensors that can document the www (world wide weather). Just add easynet and respond to requests. Someone will collect the data, create a data base and open that for global analysis. Don't ask, what the climate can do for you, do ask, what you can do for the climate!
I don‘t want to stop the show, so any contribution that acquires data from one pin and streams it to a memory of any type is a good start. Why not have the input connected to a Morse key and echo it to a led or make sound
I'm guessing the show has not stopped but got less visible . Nothing wrong with that, I think.
I asked about the minimum hardware base mainly to establish if Peter intends to use his P2D2 as a module glued to some base board (P2LAB ?) rather than designing a completely new board. While it would be very convenient to use a superb module a P2D2 surely is, I imagine there might be some hardware requirements that may need to be taken into account for a device mentioned in the thread title.
What you described in your posts above looks to me more like a network connected sensor hub with data logging capabilities. Also you seem to concentrate more on the software side of things while in this particular case I think the hardware is no less important. That is not to say the software controlling the hardware will be trivial but how complicated it will be is also defined by the hardware. Moreover, I think having the hardware base established could help in getting more embedded software developers on board so there could be more than just TAQOZ version of the firmware developed for the CheckMate, if that is considered.
If that doesn't make sense than I obviously misunderstood the whole idea of the CheckMate so please, correct me if I'm wrong.
ScopeCorder DL950 is something to look at. If we can synchronize a lot of PDAU's we easily outperfom such a system, as we distribute acquisition, measure in real time globally, ....
Yes, it's about hardware. Yes, it's about software. And, yes, it's about a common effort. We should not hesitate to start, as we want to be ready, once Peter finishes the first batch of P2D2 +++
I think keeping the expectations at the reasonably low level might save us many disappointments.
To be fair I thought it to be more like this device combined with this one, functionally speaking. But then again, maybe I got the whole idea wrong in the first place.
@Maciek said:
I think keeping the expectations at the reasonably low level might save us many disappointments.
yes. Look: it's 50 years since the advent of the 4004. This chip was created not to meet the expectations of the ordering customer, but the order opened the way to make a dream true. When they made this first chip they clearly envisioned what we have today, but threatend by this vision of chaos they clocked that chip with 400 kHz. But here we are.
@Maciek said:
I think keeping the expectations at the reasonably low level might save us many disappointments.
yes. Look: it's 50 years since the advent of the 4004. This chip was created not to meet the expectations of the ordering customer, but the order opened the way to make a dream true. When they made this first chip they clearly envisioned what we have today, but threatend by this vision of chaos they clocked that chip with 400 kHz. But here we are.
Detailed and accurate? I prefer first hand history (from the designer). I don't see anywhere in that page that they even mention F.F at all (http://www.intel4004.com). I think ErNa is Italian as well.
I would like too - (in the future) - some details from Chip itself about how he made the P2. (Even if he is usually too modest to admit that he has been 'guilty' for this. He always say that he put some others ideas into 10x10mm. But we know he is guilty)
Comments
I would like to use a P2 as the core of a complete software defined hf transceiver for portable / field use. Much of the basic hardware and software would be the same as for a test instrument. I know it's possible to do, because others have done it with much less cpu. 8 cores means the signal streams, tuning, gui etc can all run in parallel, rather than bumping into each other.
That's a fair way off, like ErNa says, there's a lot of bottom-up 'bios' to develop first.
More random thoughts on oscilloscope-like instruments:-
Oscilloscopes are like motorbikes - the markets for both are very conservative, in that everyone knows what a motorbike should look and sound like. If you gave a modern scope to a time-traveller engineer from the 1940s he would start making measurements almost immediately. The same rotary controls, same functions, admittedly buttons instead of toggle switches, softkeys instead of multiposition switches. I don't know of any make that just uses touch screens - maybe with such a 'hands on' tool they quickly get very greasy.
I remember that the first Hewlett Packard digital oscilloscopes used to stay in the equipment store from one year end to the next, no-one wanted to use the nearly-all-button and one rotary control instruments. Menus within menus - oh dear! Tektronix, LeCroy and so on wisely stayed with something much closer to the traditional look and feel. The HP scopes were slower to use, even when you got familiar.
The little credit card sized instruments radio hams have taken too in big numbers are touch screen controlled by a series of menus. In practice, most folks miss-key a lot of the time using a finger. A stylus becomes almost essential with such tiny selection areas. I have to use glasses to read the screen, which is not the case with my chinese scope. The 8" diagonal screen is easy to read with the naked eye and menus are selected by five horizontal and five vertical buttons that are 'softkeys'. There are no less than 8 rotary controls that do what scopes have always done.
Our 1940s engineer would be amazed at how shallow the case is - no huge crt - and the fact that the instrument isn't a two-man lift, it's a one-finger lift.
Just a little rotary control suggestion - if any are included that is - use knobs with colour coded caps. With controls that serve several purposes, the GUI elements can be colour coded to match the knobs, thus helping the user remember what knob controls what element on screen. (Same idea as scope probes with little coloured bands to tell one from another)
Lots of good observations by bob_g4bby but these also prompt me to ask about the general idea of this CheckMate device.
My understanding is the CheckMate is intended to be more like the Logic Analyzer with some additional DSO like capabilities rather than a full featured DSO (with all these mechanical controls, screen etc.) with a LA capabilities.
Is that so, or am I misinterpreting something ?
I think it's best to clarify that in the beginning. Also the presence (or lack of) screen/mechanical controls should be declared early on, I think. If you ask me, I don't need them on the device despite the fact I very much like the quality mechanical knobs and switches.
We can talk about this till the end of time, better to learn by doing. If I want to show what I want to do the best is to show that it doen't work yet. Someone will jump in and help. We have different choices of hardware: The evaluation board, a starter bundle or even some have a P2D2. Also there are LCD screens around, with or without touch screen. That more or less is all we need to start. I'm currently fighting with SED to understand some of Peter's tricks and find the traps he set up ;-) . My goal is to edit programs in the SD card and so have a self contained system that later will need just a keyboard to modify and test programs in the field. We can fully test ADC and data logging and filtering and... if we remember, that the P2 has independent COGs and can be used as a signal generator, so the signals created are always faster then the acquistion speed and all the developments can be done without external component. If we have them, attaching should not be the problem.
Whatever you say, but my experience tells me if we take that "let's do it and we'll see what comes out of it" approach we might find ourselves with lots of fun while doing "it" but also lots of frustrations with "it" itself later on, if we ever get to the point of finishing whatever that might be.
If we do not define what we are to achieve, we will never know if we have really achieved our goal.
The bigger and more complicated the project is, the higher the chance of failure. And we need this project to be a success.
Did you ever hear that a not plan failed? In contrast, most plans fail.
No plan never fails but rarely delivers
.
I just hope the plans that fail are for bad things and these rare ones that succeed are for good things only.
But I'm biased. I used to be a project manager for a major financial institution for many years. Most of the times back then I prayed somebody proved me wrong with my fears, but these prayers were very rarely heard up there in the sky.
Heard about evolution? It's when you surwife a perfect plan.
Well, any 'scope like' test instrument needs to stream data, display that data in a graph, handle real or virtual buttons, display menus over a live screen - lots of 'bios' facilities to develop without knowing just what the instrument will tune out to be. It might be an idea to standardise on a popular touch display, then everybody can start off with the P2 board they have (I have none yet) and start knocking out these low level features in the software that any instrument would use. Find out what features particularly fits the P2 and the display? This is bottom-up exploration of the concept. I did the same developing an antenna controller last year - just started moving stepper motors and meandered upwards to the final app.
If you plan to succeed then you have succeeded in planning. Good luck to you. As for the rest of us we plan to have lots of fun and if nothing works out then we would have had lots of fun.
The "fun" factor is what gets the creative juices going and pushes us beyond what we would normally stop pushing at. The whole process is a learning experience and that experience is continually built upon to go to the next level. So what if the first design, does A B C but not X Y Z? .... yet.
For those who desire lots of colored knobs, then you can have them. Just want a touch screen? Then you can have it. Some might like a command line interface where they can conjure up all kinds of tricks with quick n dirty one-liners. They can have it.
All these ideas are great and grand ideas and should be declared "impossible" just so that we can then focus on proving otherwise.
I'm starting to get a bit excited about this project. Are you?
A true visionary and a pragmatic man !
What I really like and appreciate is that you speak your mind no matter what others might think of it. And so do I. And i do not see a reason why that should ever change.
Point, shoot, bull's eye.
And NO, I am not starting to be excited about this project. I have been REALLY excited about it even before this thread started. And I NEED this nifty tool too so YES, I'm in for the fun
.
The software teams at my last workplace used the 'Scrum' method of managing collaboration on a project - I'm not suggesting such formalism, but the themes are interesting:-
The Agile methodology was developed as a response to growing frustrations with Waterfall and other highly structured, inflexible methodologies. This approach is designed to accommodate change and the need to produce software faster.
Agile values individuals and their relationships and interactions over tools; it features customer collaboration throughout the development process; it responds to change instead of following a set-in-stone plan; and it focuses on presenting working software, rather than documentation.
Unlike Waterfall, Agile is well equipped to handle the complexity and variability involved in development projects.Using the Agile approach, teams develop in short sprints or iterations, each of which includes a defined duration and list of deliverables, but in no particular order. During sprints, teams work towards the goal of delivering working software (or some other tangible, testable output).
Agile is collaboration-heavy, focusing on team strengths and efficiency, along with internal feedback from various departments and clients. Client satisfaction is the highest priority with the Agile approach, which teams achieve by continuously delivering working, tested, prioritized features.
Another way to implement the Agile approach, Scrum borrows from Agile’s foundational beliefs and philosophy that teams and developers should collaborate heavily and daily.
With Scrum, software is developed using an iterative approach in which the team is front and center—experienced and disciplined workers on smaller teams might find the most success with this method, as it requires self-organization and self-management.
Team members break down end goals into smaller goals at the beginning and work through them using fixed-length iterations—or sprints—to build software and showcase it often (which usually last two weeks). Meetings play an important role in the Scrum approach, and during each sprint, daily planning meetings and demos take place to follow progress and gather feedback. This incremental method promotes quick changes and development and adds value to complex projects. Scrum incorporates the structure and discipline of more traditional software development methodologies with the flexibility and iterative practices of modern Agile.
I remember the application under development was maintained in a state that would run at any time during the project (however incomplete). That's a lot like many open source ham radio projects that slowly evolve from a basic working receiver, to transceiver, to transceiver with lots of bells and whistles.
Methodologies and individual needs/wants aside, can we possibly start with establishing the minimum hardware base for what will eventually constitute a CheckMate ?
All options are on the table and I will take a NO as a valid answer too.
A p2 and a terminal
Generally speaking, I think I can guess what you mean but that is not what I had hoped for. I dare to say that this is too minimal but my skills and experiences are limited.
I admire your bravery but struggle hard to say no more.
I want to show a simple example: In my garden there is a little well. I want to log continuously the water flow. The source of the water is rain and ground water and the goal is to determine the contributions of the two sources. There is a level detector in the well, a pump, a meter to measure the outflow, a meter to measure the rainfall. So the task is quite simple: the input of the level sensor switches the pump, the ticks from the meters are to log. In the end I know how quickly the well reacts on rainfall (water entering the well directly) and how much water goes to the ground water and then to the well. There have to be some filter operations and correlations. This setup can be realized with a few digital I/Os, need some counting and is a good exercise to test the EDF. And to see how to do such a job in forth using TAQOZ. If you like you can measure blood pressure, your breath, heart beat, sleep quality... Add a microphone to find out if you snore really or if that is only hearsay ;-)
If this task looks to simple: it's the first step to a global network of sensors that can document the www (world wide weather). Just add easynet and respond to requests. Someone will collect the data, create a data base and open that for global analysis. Don't ask, what the climate can do for you, do ask, what you can do for the climate!
I don‘t want to stop the show, so any contribution that acquires data from one pin and streams it to a memory of any type is a good start. Why not have the input connected to a Morse key and echo it to a led or make sound
I'm guessing the show has not stopped but got less visible
. Nothing wrong with that, I think.
I asked about the minimum hardware base mainly to establish if Peter intends to use his P2D2 as a module glued to some base board (P2LAB ?) rather than designing a completely new board. While it would be very convenient to use a superb module a P2D2 surely is, I imagine there might be some hardware requirements that may need to be taken into account for a device mentioned in the thread title.
What you described in your posts above looks to me more like a network connected sensor hub with data logging capabilities. Also you seem to concentrate more on the software side of things while in this particular case I think the hardware is no less important. That is not to say the software controlling the hardware will be trivial but how complicated it will be is also defined by the hardware. Moreover, I think having the hardware base established could help in getting more embedded software developers on board so there could be more than just TAQOZ version of the firmware developed for the CheckMate, if that is considered.
If that doesn't make sense than I obviously misunderstood the whole idea of the CheckMate so please, correct me if I'm wrong.
ScopeCorder DL950 is something to look at. If we can synchronize a lot of PDAU's we easily outperfom such a system, as we distribute acquisition, measure in real time globally, ....
Yes, it's about hardware. Yes, it's about software. And, yes, it's about a common effort. We should not hesitate to start, as we want to be ready, once Peter finishes the first batch of P2D2 +++
I think keeping the expectations at the reasonably low level might save us many disappointments.
To be fair I thought it to be more like this device combined with this one, functionally speaking. But then again, maybe I got the whole idea wrong in the first place.
yes. Look: it's 50 years since the advent of the 4004. This chip was created not to meet the expectations of the ordering customer, but the order opened the way to make a dream true. When they made this first chip they clearly envisioned what we have today, but threatend by this vision of chaos they clocked that chip with 400 kHz. But here we are.
Is this project idea still alive ?
It looked very promising a month ago.
Go to "https://www.intel.com/content/www/us/en/history/museum-story-of-intel-4004.html" for a slightly more detailed and accurate description of the birth of the microcomputer. It was used in a lot of instrumentation.
Detailed and accurate? I prefer first hand history (from the designer). I don't see anywhere in that page that they even mention F.F at all (http://www.intel4004.com). I think ErNa is Italian as well.
But remember that there was (at least) another one before 4004. (Ray Holt MP944 https://firstmicroprocessor.com/).
I would like too - (in the future) - some details from Chip itself about how he made the P2. (Even if he is usually too modest to admit that he has been 'guilty' for this. He always say that he put some others ideas into 10x10mm. But we know he is guilty)