Providing real-time performance in an OS with multiple cores
Providing real-time performance in an OS with multiple cores
Typically, reliable, fast real-time responses cannot be achieved on top of traditional OSes (for instance because of interrupts, scheduler-locks, pagefaults), and RDOS is no exception. Instead, such software usually needs to be run on a microcontroller without any real OS.
I have an interesting project coming up which will look into this. Originally, my thought was this would need some PIC-chips, but maybe not. There are now affordable Dual-core Intel Atom boards with PC/104 expansion that could interface with real hardware. My project will control a wind generator, and pulse it into a load at at rather high frequency (several kHz). At the same time it should maximize the power generated by controlling the mean voltage after pulsing the load. When the wind is weak, the pulse-widths should be short in order for the blades to move close to the speed of the wind (this would generate optimal power-output). When wind is stronger, longer pluse-widths should be used in order to load the generator more. IOW, not only is there a need to generate pulses at several kHz, the pulse widths must also be correct. This is a task that a typical OS will fail at.
So how would I do this under RDOS? I will add functionality to reserve a core for a special task. Then the wind controller could run on a dedicated core, and would be able to meet the requirements.
There are some complications though:
* IPIs should not be sent to dedicated cores (this would sabotage real-time performance)
* General interrupts should not be delivered to dedicated cores
* There needs to be some way to communicate between dedicated cores and the main OS
Regarding IPIs, this means that "send-to-all-except-self" cannot be used. In fact, RDOS does not use this function when sending IPIs for precisely this reason, but rather would send individial IPIs to cores (even if it is "all-except-self")
The second issue could be solved by setting processor priority to 15. Additionally, the LDR should be setup not to match "lowest-priorty" interrupts.
The third issue is the toughest one. This is expecially so since the dedicated core should never use scheduler-related functions directly or indirectly. There will be a need for special critical sections for dedicated cores (that uses spinlocks instead of blocks), that can coexist with ordinary threads. There will also be a need for a spinlock-based WaitForSignal.
Additionally, it should be possible to assign interrupts to the dedicated core.
Dedicated cores should also have a high-precision timer function (which does not involve the scheduler). This would be used for generating pulse-widths, so it would not be necesary to use busy-loops that would consume a lot of energy. This could be implemented by reloading the the APIC timer with another int-destination.
I have an interesting project coming up which will look into this. Originally, my thought was this would need some PIC-chips, but maybe not. There are now affordable Dual-core Intel Atom boards with PC/104 expansion that could interface with real hardware. My project will control a wind generator, and pulse it into a load at at rather high frequency (several kHz). At the same time it should maximize the power generated by controlling the mean voltage after pulsing the load. When the wind is weak, the pulse-widths should be short in order for the blades to move close to the speed of the wind (this would generate optimal power-output). When wind is stronger, longer pluse-widths should be used in order to load the generator more. IOW, not only is there a need to generate pulses at several kHz, the pulse widths must also be correct. This is a task that a typical OS will fail at.
So how would I do this under RDOS? I will add functionality to reserve a core for a special task. Then the wind controller could run on a dedicated core, and would be able to meet the requirements.
There are some complications though:
* IPIs should not be sent to dedicated cores (this would sabotage real-time performance)
* General interrupts should not be delivered to dedicated cores
* There needs to be some way to communicate between dedicated cores and the main OS
Regarding IPIs, this means that "send-to-all-except-self" cannot be used. In fact, RDOS does not use this function when sending IPIs for precisely this reason, but rather would send individial IPIs to cores (even if it is "all-except-self")
The second issue could be solved by setting processor priority to 15. Additionally, the LDR should be setup not to match "lowest-priorty" interrupts.
The third issue is the toughest one. This is expecially so since the dedicated core should never use scheduler-related functions directly or indirectly. There will be a need for special critical sections for dedicated cores (that uses spinlocks instead of blocks), that can coexist with ordinary threads. There will also be a need for a spinlock-based WaitForSignal.
Additionally, it should be possible to assign interrupts to the dedicated core.
Dedicated cores should also have a high-precision timer function (which does not involve the scheduler). This would be used for generating pulse-widths, so it would not be necesary to use busy-loops that would consume a lot of energy. This could be implemented by reloading the the APIC timer with another int-destination.
Re: Providing real-time performance in an OS with multiple c
Hi,
Cheers,
Brendan
Why do you need any software at all? To me it sounds like you need a suitable (but simple) electronic circuit - no CPU, no software.rdos wrote:My project will control a wind generator, and pulse it into a load at at rather high frequency (several kHz). At the same time it should maximize the power generated by controlling the mean voltage after pulsing the load. When the wind is weak, the pulse-widths should be short in order for the blades to move close to the speed of the wind (this would generate optimal power-output). When wind is stronger, longer pluse-widths should be used in order to load the generator more. IOW, not only is there a need to generate pulses at several kHz, the pulse widths must also be correct. This is a task that a typical OS will fail at.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Providing real-time performance in an OS with multiple c
Some parts of this project is electronics, but the part that optimizes power-output (and meassures power output) must be software. In order to measure power output, there is a need to multiply current and voltage, something that cannot be easily done with electronics alone. The optimization algorithm would fine-tune the pulse-ratio by calculating power, and keeping previous power ratings, in order to estimate a new setting that would optimize power. Neither voltage nor current are constant when power is optimized. The available wind power is proportional to the cube (x3) of wind-speed, while voltage is proportional to the rotation speed, and wind-speed. Power is U x I, or U ^ 2 / R, which is the square of wind-speed. That means that voltage needs to increase with wind-speed.Brendan wrote:Why do you need any software at all? To me it sounds like you need a suitable (but simple) electronic circuit - no CPU, no software.
Re: Providing real-time performance in an OS with multiple c
Hi,
The load effects the rotational speed and the wind power effects the rotational speed. By allowing the rotational speed (and nothing else) to control the pulse width, it'll automatically find an optimal "balance" for the current load and current wind power.
Now imagine some sort of position sensor to measure the rotational speed; that produces a series of pulses where frequency depends on rotational speed and duty cycle is always 50%. For the position sensor, I'm thinking of an LED that shines light through a ring with slots onto a photo-diode; where the "ring with slots" is mounted behind the fan blades and spins.
At the falling edge of this sensor signal start a timer, and AND the sensor signal with the output of the timer.
Optimal Rotational Speed:
Rotational Speed Too High:
Rotational Speed Too Low:
The timer can be a simple capacitor and resistor, the AND gate can be a transistor. You might need a NOT gate/inverter between sensor and the timer, so throw in another transistor. Total cost of parts = $5. Could probably get a proto-type working in a day, and because it's so simple the chance of hardware and software failures is practically zero.
If you need to measure the output power at all, then you could slap one of these "extremely rare" power meters on it, because you obviously need a modern CPU to measure power...
Cheers,
Brendan
I was thinking more of a self-balancing system.rdos wrote:Some parts of this project is electronics, but the part that optimizes power-output (and meassures power output) must be software. In order to measure power output, there is a need to multiply current and voltage, something that cannot be easily done with electronics alone. The optimization algorithm would fine-tune the pulse-ratio by calculating power, and keeping previous power ratings, in order to estimate a new setting that would optimize power. Neither voltage nor current are constant when power is optimized. The available wind power is proportional to the cube (x3) of wind-speed, while voltage is proportional to the rotation speed, and wind-speed. Power is U x I, or U ^ 2 / R, which is the square of wind-speed. That means that voltage needs to increase with wind-speed.Brendan wrote:Why do you need any software at all? To me it sounds like you need a suitable (but simple) electronic circuit - no CPU, no software.
The load effects the rotational speed and the wind power effects the rotational speed. By allowing the rotational speed (and nothing else) to control the pulse width, it'll automatically find an optimal "balance" for the current load and current wind power.
Now imagine some sort of position sensor to measure the rotational speed; that produces a series of pulses where frequency depends on rotational speed and duty cycle is always 50%. For the position sensor, I'm thinking of an LED that shines light through a ring with slots onto a photo-diode; where the "ring with slots" is mounted behind the fan blades and spins.
At the falling edge of this sensor signal start a timer, and AND the sensor signal with the output of the timer.
Optimal Rotational Speed:
Code: Select all
Sensor signal = --____----____----
| <- falling edge of sensor signal starts timer
Timer output = __------__------__
AND output = ______--______--__ (25% duty cycle)
Code: Select all
Sensor signal = --___---___---
| <- falling edge of sensor signal starts timer (before it expired)
Timer output = ----------------
AND output = --___---___--- (50% duty cycle)
Code: Select all
Sensor signal = --______------______------
| <- falling edge of sensor signal starts timer
Timer output = __------______------______
AND output = __________________________ (0% duty cycle)
If you need to measure the output power at all, then you could slap one of these "extremely rare" power meters on it, because you obviously need a modern CPU to measure power...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Providing real-time performance in an OS with multiple c
Rotational speed is approximately proportional to output voltage. When the wind generator is unloaded, it usually outputs 65-70v (if it isn't almost wind-free). If you for instance load it with 13 ohm (as I do know for a test), it will rotate very slowly, and output voltage would be around 1-2 volts for moderate winds, but if the load had instead been 100 ohm, it would have an output voltage of perhaps 25v. In the first case, the generated power is less than 1W, while in the latter it is 6.25W. IOW, there is much to win by optimizing rotational speed.Brendan wrote:I was thinking more of a self-balancing system.
The load effects the rotational speed and the wind power effects the rotational speed. By allowing the rotational speed (and nothing else) to control the pulse width, it'll automatically find an optimal "balance" for the current load and current wind power.
I think this will be kind of hard to implement. The wind turbin (a Rutland 913 rated for 24v) is already mounted on a 9.5 metre high pole, and I'm not likely to mount anything on top of it.Brendan wrote: Now imagine some sort of position sensor to measure the rotational speed; that produces a series of pulses where frequency depends on rotational speed and duty cycle is always 50%. For the position sensor, I'm thinking of an LED that shines light through a ring with slots onto a photo-diode; where the "ring with slots" is mounted behind the fan blades and spins.
But as I wrote above, rotational speed is approximately proportional to voltage. When it runs free-running, it usually outputs up to 70v, but then the voltage decrease as it gets loaded more and thus rotates slower.
The problem is that you lack a parameter: Actual wind speed.
Part of the project is to log wind power, and a few other parameters, and possibly putting them on a web-site. I also have a 40W solar panel that I aim to measure cloudiness with. This can be achieved by comparing sun height with power generated by solar panel. Of course, the aim is that the whole project should run on it's own power.Brendan wrote: If you need to measure the output power at all, then you could slap one of these "extremely rare" power meters on it, because you obviously need a modern CPU to measure power...
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
Re: Providing real-time performance in an OS with multiple c
Is a dedicated core necessary. Can't you change the scheduler to a dead line scheduler and busy wait the remaining time for that extra accuracy, also ensuring that the core will not be interrupted during that time? Though, if it is at several kHz there it will be a significant hit on performance so there is the question when it starts to become useless to have scheduling on that CPU at all.
Re: Providing real-time performance in an OS with multiple c
It would be possible to solve this with some additional hardware (like a PWM generator), and by letting the server thread run at higher-than normal priority, but I see this as a good setup for implementing hard-realtime extensions to RDOS.OSwhatever wrote:Is a dedicated core necessary. Can't you change the scheduler to a dead line scheduler and busy wait the remaining time for that extra accuracy, also ensuring that the core will not be interrupted during that time? Though, if it is at several kHz there it will be a significant hit on performance so there is the question when it starts to become useless to have scheduling on that CPU at all.
Re: Providing real-time performance in an OS with multiple c
RDOS might be a special case, but generally speaking it is very hard to retroactively put any "hard" realtime (which is about proofs and guarantees) into an existing system. You might be better off with a dedicated solution.
Every good solution is obvious once you've found it.
Re: Providing real-time performance in an OS with multiple c
Yes, this is true. However, what I would do is to build a partly new environment that can garantee deadlines and hard real-time since the dedicated core is not used by RDOS. The part that interfaces with RDOS would not be able to garantee deadlines, but if the application is "self-contained" it could garantee deadlines.Solar wrote:RDOS might be a special case, but generally speaking it is very hard to retroactively put any "hard" realtime (which is about proofs and guarantees) into an existing system. You might be better off with a dedicated solution.
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
Re: Providing real-time performance in an OS with multiple c
There is also the option to use virtualization to have one "user OS" and one RTOS running on the same HW. This solution has already been suggested by many and companies already sell products for these kind of systems (usually Linux together with some RTOS).
Re: Providing real-time performance in an OS with multiple c
Why is there a need for virtualization, and how could a virtualized RTOS environment guarantee that deadlines are met?OSwhatever wrote:There is also the option to use virtualization to have one "user OS" and one RTOS running on the same HW. This solution has already been suggested by many and companies already sell products for these kind of systems (usually Linux together with some RTOS).
Re: Providing real-time performance in an OS with multiple c
Hi,
For interfacing the thing to a computer (measuring voltage supplied by the generator, and current delivered to the load by measuring the voltage across a low ohm resistor in series with the load), I'd be tempted to use sound cards (and voltage dividers - 2 resistors). Sound cards have a fairly accurate analog-to-digital converters with a sample rate that is overkill; but more importantly they have bus mastering/DMA (and buffers) so you don't need a real time OS. You could also probably buy special cards designed for instrumentation (e.g. capable of capturing signals up to 2 GHz, with some isolation on the inputs to protect the computer, etc) but they're probably a lot more expensive too.
To measure wind speed, you need something designed to measure wind speed.
For a very cheap anemometer, rip apart an old "ball mouse" (not a newer optical mouse) and have a look. You'll see a pair of little wheels that create pulses when they turn; and you'd be able to create a type of cup anemometer that drives one of these little wheels inside the mouse (could probably use 2 wooden pencils and a some paper cups if your budget is tight), and connect it to a computer using the existing PS/2 or USB mouse interface. The bonus here is that your OS probably already has a mouse driver.
Cheers,
Brendan
That makes it sound even easier - if output voltage is above 28.8v you attach the load (via. a voltage regulator) to slow the rotational speed down, and if output voltage is less than 28.8v you don't. Note: If I remember right, 28.8v is the voltage you'd want to charge a 24v truck battery (so what I've described here is probably how the generator is designed to be used), and you'd need to charge a battery to keep the system running on it's own power (on calm dark nights).rdos wrote:Rotational speed is approximately proportional to output voltage. When the wind generator is unloaded, it usually outputs 65-70v (if it isn't almost wind-free). If you for instance load it with 13 ohm (as I do know for a test), it will rotate very slowly, and output voltage would be around 1-2 volts for moderate winds, but if the load had instead been 100 ohm, it would have an output voltage of perhaps 25v. In the first case, the generated power is less than 1W, while in the latter it is 6.25W. IOW, there is much to win by optimizing rotational speed.Brendan wrote:I was thinking more of a self-balancing system.
The load effects the rotational speed and the wind power effects the rotational speed. By allowing the rotational speed (and nothing else) to control the pulse width, it'll automatically find an optimal "balance" for the current load and current wind power.
For interfacing the thing to a computer (measuring voltage supplied by the generator, and current delivered to the load by measuring the voltage across a low ohm resistor in series with the load), I'd be tempted to use sound cards (and voltage dividers - 2 resistors). Sound cards have a fairly accurate analog-to-digital converters with a sample rate that is overkill; but more importantly they have bus mastering/DMA (and buffers) so you don't need a real time OS. You could also probably buy special cards designed for instrumentation (e.g. capable of capturing signals up to 2 GHz, with some isolation on the inputs to protect the computer, etc) but they're probably a lot more expensive too.
The problem is you have nothing to measure the wind speed/power. For example, if the generator has no load at all and is producing 70v, does that mean the wind speed/power is 150 km/h or 300 km/h; and if the generator is producing 0v does that mean the wind speed/power is 0 km/h or 5 km/h? If the generator with no load can't measure wind speed/power, then you can't use it to estimate the wind speed/power when there is a load either.Brendan wrote:The problem is that you lack a parameter: Actual wind speed.
To measure wind speed, you need something designed to measure wind speed.
For a very cheap anemometer, rip apart an old "ball mouse" (not a newer optical mouse) and have a look. You'll see a pair of little wheels that create pulses when they turn; and you'd be able to create a type of cup anemometer that drives one of these little wheels inside the mouse (could probably use 2 wooden pencils and a some paper cups if your budget is tight), and connect it to a computer using the existing PS/2 or USB mouse interface. The bonus here is that your OS probably already has a mouse driver.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Providing real-time performance in an OS with multiple c
Sure, that is the usual way it is used, but it is not optimal. When wind is very weak, the generator never achieve 28.8v, and thus does not charge at all. As wind speed increases, load would become to high, and the blades would therefore rotate at a too low velocity for optimal power production. The same thing happens when wind is strong. If the generator is directly coupled to the batteries, there is a need to disconnect it in order not to overload batteries with a too high voltage (again no energy produced). There is only a small range of wind-speeds that achieve optimal power production, which the generator is usually adapted for. Just because most uses are simple, doesn't mean they achieve optimal power production. In order to produce as much energy as possible, voltage must be proportional to wind-speed, and the load needs to increase with increasing wind-speed. That is not achieved in a simple battery charger, as it operates with constant voltage and a load that is dependent on how much the battery is charged.Brendan wrote:That makes it sound even easier - if output voltage is above 28.8v you attach the load (via. a voltage regulator) to slow the rotational speed down, and if output voltage is less than 28.8v you don't. Note: If I remember right, 28.8v is the voltage you'd want to charge a 24v truck battery (so what I've described here is probably how the generator is designed to be used), and you'd need to charge a battery to keep the system running on it's own power (on calm dark nights).
In a situation where batteries are charged, there is a need to add a DC/DC step-down converter that transforms the optimal voltage to something that is optimal to charge batteries. If all energy should be used, there is also a need for a "default-load" where power can be sent when batteries are full, or the generator delivers more energy than can be used (or the voltage is below the minimum of the DC/DC step-down converter). The default load can be something like a heater for warm-water.
The most efficient solution is a microcontroller with a hardware multiplier, a few AD channels, a PWM, and some additional hardware, as it uses minimal power.Brendan wrote:For interfacing the thing to a computer (measuring voltage supplied by the generator, and current delivered to the load by measuring the voltage across a low ohm resistor in series with the load), I'd be tempted to use sound cards (and voltage dividers - 2 resistors). Sound cards have a fairly accurate analog-to-digital converters with a sample rate that is overkill; but more importantly they have bus mastering/DMA (and buffers) so you don't need a real time OS. You could also probably buy special cards designed for instrumentation (e.g. capable of capturing signals up to 2 GHz, with some isolation on the inputs to protect the computer, etc) but they're probably a lot more expensive too.
Actually, that is wrong. When the regulator algorithm I described before is used, the resulting voltage would be proportional to wind-speed, simply because rotational velocity under optimal power generation conditions is proportional to wind-speed. Because of this, it would be possible to calibrate to actually meassure wind-speed.Brendan wrote:The problem is you have nothing to measure the wind speed/power. For example, if the generator has no load at all and is producing 70v, does that mean the wind speed/power is 150 km/h or 300 km/h; and if the generator is producing 0v does that mean the wind speed/power is 0 km/h or 5 km/h? If the generator with no load can't measure wind speed/power, then you can't use it to estimate the wind speed/power when there is a load either.
Re: Providing real-time performance in an OS with multiple c
Hi,
If you are willing to waste lots of time, effort and money creating an over-engineered solution in the hope of achieving optimal usable power production; then you're using the wrong type of generator. What you'd need is a generator with a set of rotating windings (the rotor) and a set of fixed windings (the stator). By controlling the voltage applied to the rotor you control the voltage generated in the stator, and don't need to lose efficiency in later voltage conversion steps.
Cheers,
Brendan
Don't confuse optimal power production with optimal usable power production. Is producing the optimal amount of power and then wasting around 80% of it in a some sort of variable voltage DC to fixed voltage converter really going to be "optimal"?.rdos wrote:Sure, that is the usual way it is used, but it is not optimal. When wind is very weak, the generator never achieve 28.8v, and thus does not charge at all. As wind speed increases, load would become to high, and the blades would therefore rotate at a too low velocity for optimal power production. The same thing happens when wind is strong. If the generator is directly coupled to the batteries, there is a need to disconnect it in order not to overload batteries with a too high voltage (again no energy produced). There is only a small range of wind-speeds that achieve optimal power production, which the generator is usually adapted for. Just because most uses are simple, doesn't mean they achieve optimal power production. In order to produce as much energy as possible, voltage must be proportional to wind-speed, and the load needs to increase with increasing wind-speed. That is not achieved in a simple battery charger, as it operates with constant voltage and a load that is dependent on how much the battery is charged.Brendan wrote:That makes it sound even easier - if output voltage is above 28.8v you attach the load (via. a voltage regulator) to slow the rotational speed down, and if output voltage is less than 28.8v you don't. Note: If I remember right, 28.8v is the voltage you'd want to charge a 24v truck battery (so what I've described here is probably how the generator is designed to be used), and you'd need to charge a battery to keep the system running on it's own power (on calm dark nights).
If you are willing to waste lots of time, effort and money creating an over-engineered solution in the hope of achieving optimal usable power production; then you're using the wrong type of generator. What you'd need is a generator with a set of rotating windings (the rotor) and a set of fixed windings (the stator). By controlling the voltage applied to the rotor you control the voltage generated in the stator, and don't need to lose efficiency in later voltage conversion steps.
I thought you were using RDOS running on an Atom board because you didn't feel like using (for e.g.) PIC microcontrollers?rdos wrote:The most efficient solution is a microcontroller with a hardware multiplier, a few AD channels, a PWM, and some additional hardware, as it uses minimal power.
The troubleshooting section of the Rutland 913 user manual implies that you need "sufficient wind" to get any voltage out of it at all, so I'd assume that for wind speeds below "something" (maybe 5 km/h - hard to tell) you 0 v and would therefore be unable to use the generator to measure slower wind speeds. I thought someone said "When the wind generator is unloaded, it usually outputs 65-70v (if it isn't almost wind-free).", which seems to me to be an extremely small voltage range for an (assumed) much larger range of wind speeds. Then there's "prolonged gales" where the built-in thermostat kicks in and you get 0v.rdos wrote:Actually, that is wrong. When the regulator algorithm I described before is used, the resulting voltage would be proportional to wind-speed, simply because rotational velocity under optimal power generation conditions is proportional to wind-speed. Because of this, it would be possible to calibrate to actually meassure wind-speed.Brendan wrote:The problem is you have nothing to measure the wind speed/power. For example, if the generator has no load at all and is producing 70v, does that mean the wind speed/power is 150 km/h or 300 km/h; and if the generator is producing 0v does that mean the wind speed/power is 0 km/h or 5 km/h? If the generator with no load can't measure wind speed/power, then you can't use it to estimate the wind speed/power when there is a load either.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Providing real-time performance in an OS with multiple c
Switching DC/DC converters typically have 90% efficiency, so that is hardly an issue. They are also relatively cheep if done with basic building-blocks instead of complete ICs solutions.Brendan wrote:Don't confuse optimal power production with optimal usable power production. Is producing the optimal amount of power and then wasting around 80% of it in a some sort of variable voltage DC to fixed voltage converter really going to be "optimal"?.
Possibly, but now I've got the present solution and I'll have to stick to that.Brendan wrote:If you are willing to waste lots of time, effort and money creating an over-engineered solution in the hope of achieving optimal usable power production; then you're using the wrong type of generator. What you'd need is a generator with a set of rotating windings (the rotor) and a set of fixed windings (the stator). By controlling the voltage applied to the rotor you control the voltage generated in the stator, and don't need to lose efficiency in later voltage conversion steps.
Yes, I will problably waste some 10W on an Intel Atom board instead, I was just giving the most effcient solution.Brendan wrote:I thought you were using RDOS running on an Atom board because you didn't feel like using (for e.g.) PIC microcontrollers?rdos wrote:The most efficient solution is a microcontroller with a hardware multiplier, a few AD channels, a PWM, and some additional hardware, as it uses minimal power.
After all, I need something to consume the energy produced.
That is not my experience. I suspect they mean this is the case when it is used as a battery charger. If it runs unloaded, it will start to rotate in very weak winds.Brendan wrote:The troubleshooting section of the Rutland 913 user manual implies that you need "sufficient wind" to get any voltage out of it at all, so I'd assume that for wind speeds below "something" (maybe 5 km/h - hard to tell) you 0 v and would therefore be unable to use the generator to measure slower wind speeds.
There will be situations when the wind is so strong that it cannot be handled, but I don't expect to let the built-in thermostat to kick-in. Instead, the solution would limit current to 20A, and let the voltage increase above optimal values (which is what happens when the thermostat kicks-in). When this happens, voltage will not be proportional to wind-speed. However, there might be other ways to calibrate then.Brendan wrote:I thought someone said "When the wind generator is unloaded, it usually outputs 65-70v (if it isn't almost wind-free).", which seems to me to be an extremely small voltage range for an (assumed) much larger range of wind speeds. Then there's "prolonged gales" where the built-in thermostat kicks in and you get 0v.