|
"Resonators" is pretty generic term. In general - you are implying a demodulation part of the receiver where "resonators" are used for getting the final; humanely "readable" audio.
In such application crystal or ceramic resonators are OK to use.
I far as technology - the crystal resonators are sort of "things of the past" mainly due to the cost.
Do you have a schematic of your receiver ? I'll be interested to take a look.
|
|
|
|
|
yai ck,
In case it helps... Last year I restored an antique tube radio. I found the members of the forums at www.antiqueradios.com to be very knowledgeable about radio technology.
Best wishes,
Craig
|
|
|
|
|
Does anyone know a place on the Internet with actual processor zoomed in pictures showing the layout of various transistor areas on the chip. The Internet is full of diagrams, what I`m looking for is a visual representation of the components the diagrams are speaking of.
|
|
|
|
|
No. There may be some images for older stuff (like the '80's and '90's), but todays processors transistor are so small and occupy so many layers of the chip that it's not possible to see detail like that anymore.
|
|
|
|
|
Are you saying it looks like the surface of a CD with no way to differentiate between different areas?
|
|
|
|
|
CD pits are FAR larger than current transistors.
An nVidia 3090 has a die of about 25mm on a side. It contains over 28 billion transistors. There's over 45 million transistors per square MILLIMETER.
modified 9-Aug-22 10:50am.
|
|
|
|
|
At my former workplace, some of the pictures on the wall were microphotographs of the company's former chip generations, based on the 8051 architecture developed in 1980. You could easily identify rectangular areas with a regular, quite fine-grained structure: the memory banks. Other areas were more irregular; those were the CPU. Some areas with almost no identifiable structure, more like 'spotty'; that was the various I/O devices (this was an embedded type chip, with lots of I/O beyond the CPU capabilities); you could even identify a couple coils - the chip I/O included a radio.
So you could identify various areas, but it just looked like different kinds of structures, more or less regular or irregular. Seeing the shape of individual components was not possible, at least not on these wall posters.
I am talking about 40+ years old 8-bit technology (or rather: architecture), approx. 50,000 transistors for the CPU. Even with that simple chips, you wouldn't get what you are asking for. Today's 64 bit processors are extremely more dense, and complex, approaching 50 billon transistors. You will probably see "gray" areas that are likely to be the cache memory. If pointed out to you, you can probably distinguish a few other functional areas from the rest, but all you can see is that they are different from, and less regular than, the cache areas.
For the simple question of "what does a so-and-so type transistor really look like?", you can probably find 3D engineering drawings, similar to that of a MOSFET in the Wikipedia article "Transistor". But those are drawings, not the chip photographs you are asking for.
|
|
|
|
|
Do robotic arms in a car plant operate mostly based on information provided by sensors? Like they aren`t thought to operate blindly, there is a process of camera/sensor based aiming/homing (if we talk about say a welding arm) on the region where work needs to be done.
|
|
|
|
|
Depends on the application. There's a large variety of different position and control sensing methods.
|
|
|
|
|
So basically it`s a two way process(sensors can stop/modify the process of state switching), it`s not just a blind switching of states that bears no relation to the changes in the outer world.
|
|
|
|
|
No.
It's the entire range between no sensing at all to switches to detect objects to vision systems to detect objects and positions of them, and everything in-between. There is no one sensing system to rule them all.
|
|
|
|
|
One of the reasons why I`m asking is I remember seeing car plant footages from the 80`s displaying robotic arms working unassisted (by man) on car frames. Back in those days the sensor technologies were pretty much inexistent so lot`s of questions raising with regards to that kind of footage.
From what you`re saying I get that initially it was 'touching' based.
modified 9-Aug-22 6:41am.
|
|
|
|
|
Those robots were programmed to repeat a fixed set of actions with very little sensor intervention. Move forward x inches, move left y inches, spot weld for z milliseconds, move back, and wait for the next car to arrive.
|
|
|
|
|
How does the music data get stored on a CD? What I mean is you can switch between music CD tracks with the next or previous track buttons. How does the reading head know where to jump on the spiral location where the next track begins? Is there a track directory listing containing the track start position for every track on the CD?
|
|
|
|
|
Quote: Is there a track directory listing containing the track start position for every track on the CD?
Essentially, yes. There is more information at Compact Disc Digital Audio - Wikipedia[^] and the links in the reference section there
|
|
|
|
|
|
OK, first plug it in...duh...
Then run "lsusb" to verify the system actually acknowledged the new USB
Next run "gparted" - that should identify /dev .
While "gparted" is open use "Device" and "Create partition table " (gpt)
( It will take forever to run on 125GB stick...)
Create small test partition ( saves time) , use / add BOTH names
Recheck using fdisk ..
Use CLI to "mount" new USB stick -
For good measure - reboot...
After reboot the new USB file should show up in Ubuntu "file manager" AND
Ubuntu "Disks" .
This is where I get lost - it should with unexpected / different data.
"disks" shows mount point AND it may not be same as added using "mount"
the second issue is
so far the ownership of the device was not assigned
sometime that can be done in "disks" , but not while adding / activation of this new USB stick.
What did I missed?
Since I am not sure about /dev or mount point , if possible , I would prefer GUI application to change / assign ownership.
Thanks , appreciate any help.
|
|
|
|
|
good. Thank you for the information
|
|
|
|
|
Are microcontrollers in a way universal, in theory any program can fit into a microcontroller which means that the same microcontroller can fit the needs of any printed circuit board (since the program on the microcontroller can be adapted to meet the needs of any circuit board)?
I also have a question about car electronics. The car has various parameters, most of then need just to be displayed to the driver (vehicle speed, engine RPM, etc.) and it`s up to the driver to decide the amount & moment when change should be applied to those parameters. If the parameter display is digital I assume some kind of microcontroller is required to transform sensor data into humanly readable onscreen information. But my guess is that there are also parameters that are altered/changed after being read without driver intervention. In this later case the change comes from a microcontroller with a program designed to cause change. So basically a microcontroller can be used to either aid the display of information about various car components or actually change, at it`s own discretion, how those car components operate.
Are my assumptions close to how things are working in practice.
modified 10-Apr-22 10:50am.
|
|
|
|
|
I think you can assume that any microcontroller is Turing complete. So in theory, any microcontroller can replace even the most huge supercomputers. And every computer of any intermediate rank.
But then again: In theory, there is no difference between theory and practice, but in practice there may be.
Microcontrollers tend to have a very short paper tape. Clock speeds may be measured in kHz; memory sizes in kilobytes. (Well, there are as well microcontrollers running at quite a few MHz and addressing gigabytes, but some of them could deserve being called millicontrollers ...).
Microcontrollers are plain CPUs, but often packed with a lot of I/O circuitry on the chip, and some RAM / ROM / Flash - maybe all that the CPU needs in typical applications. Frequently, all that is needed is integrated on the chip, and it may be referred to as a SoC - "System on Chip".
For the car: Anything that can be read as a digital signal can be read by a microcontroller. Many microcontrollers also have one or more analog-to-digital (A/D) converters on-chip, so the signal need not even be digital outside the chip (but the handling of the reading is always done after it has been digitized). Anything that can be controlled through a digital signal can be controlled - call it 'changed', if you prefer - by a microcontroller. Likewise, microcontrollers may have on-chip digital-to-analog (D/A) converters, for (car or other) components that require an analog control signal. In a modern car, lots of components are not manipulated directly by the driver. The driver sends a signal to a controller requesting it to take the necessary steps to obtain some desired result, whether to start the engine, operate the ABS breaking system, or flash the blinkers.
This goes for almost all modern electronics: Today you hardly ever turn a potentiometer or press a switch to make a current flow. You still have dials, but they only serve as signal generators for a processor (/microcontroller) that in turn sends the "real" control signal to the component, possibly after some checking, adjustments, or reshaping.
Most likely, the rich set of I/O facilities typically integrated into the microcontroller makes it far better suited to such control tasks (guess what has inspired its name!) than, say, the typical CPUs found in desktop computers. A microcontroller usually runs a fixed set of software functions, and perform a fixed set of tasks - you boot it up with the software it will need, and do not add any more later. Knowing the tasks it will run, you will know how powerful it has to be, and you select a microcontroller accordingly. For battery driven applications you may also select clock frequency accordingly - the lower the frequency, the longer the battery life.
|
|
|
|
|
wrong forum
modified 4-Apr-22 13:06pm.
|
|
|
|
|
And you expect an answer to this without knowing anything at all about your hardware, the O/S it's running, whether it's a NAS, which vendor it is, or anything else that might be useful?
|
|
|
|
|
I am familiar with mdadm tool (Linux /Ubuntu) and so far I cannot see how to SIMPLY accomplish the task.
Is there another tool I can use ?
|
|
|
|
|
What happens when you try the --remove option?
|
|
|
|
|
I hope this question belogs here.
I have asked this many times and still have no real answer.
In multiboot ( all Linux) system "grub" has an option to boot (automatically) last used OS.
When "grub" menu is displayed such " saved " OS is indicated by asterisk (*) as
first character on the line.
However, UEFI gets into the act and FIRST option in "grub" menu is an entry
"*Ubuntu"
and it is marked , incorrectly , as "last saved OS used".
Allegedly, UEFi "boot firmware " also monitors last SUCCESSFULLY used OS...
No matter how often I change "grub" options - and then update grub - the menu ALWAYS set the asterisk next to the "Ubuntu" label.
It only works when I install new , clean Ubuntu using ISO.
...and I do change the OS using other then "Ubuntu" option in "grub" menu...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
