Hi,
When i set the PWM Frequency at the GPIO Node to 25khz
Why i just get 5,68kHz at the oscilloscope?
Nobody an idear?
the default nodes just use the python GPIO.PWM code which may be well off (though I'm surprised it's that bad) - eg see https://raspberrypi.stackexchange.com/questions/298/can-i-use-the-gpio-for-pulse-width-modulation-pwm
Thanks i will have a look at it
Seems that that the WiringPi node is discontinued.
Have to check the others...
??? - are you using the built in node to start with ?
If you have a scope and some time ... :-)... it would be great if you could do some measurements. At various frequencies from say 20Hz, 50, 100, 200, 500, 1K... etc and report the level of inaccuracy... if it's a simple function we may be able to compensate in the node - or not... Also would ideally need to try various different Pi versions to see how much is down to overheads in the OS that the processor speed can't cope with etc.
This was with the standart Node.
I will do a few test this evening
Very interesting - which Pi version is this ?
Net I take from that is this particular implementation of PWM only really works up to about 1kHz. (I'll add a note to the info to reflect this limitation)
It may be worth also looking at http://abyz.me.uk/rpi/pigpio/pigs.html#HP
The node-red-node-pi-gpiod node uses the pigpiod as it's base instead - and can also do pwm - but currently it doesn't allow frequency to be set. see https://github.com/node-red/node-red-nodes/blob/master/hardware/pigpiod/pi-gpiod.js#L149
Certainly I've used it in servo mode and it seems to be very solid timing wise - so maybe its pwm is beeter also.
Hi,
it is a 3b+
Pi-Blaster also cant 25kHz cause of a bug or something like that.
Any other ideas?
As I understand it the pigpiod will only use DMA PWM, which can work on any pin but is not as high performance as hardware PWM which is only available on certain pins (e.g. GPIO 12 and 13). I would be very interested in getting this higher performance PWM working on node-red, with frequencies up in the MHz range if required, as it also provides a much finer control that the standard 0-255 levels. I am planning to use it for control voltages on a modular synth, where the pitch control is 1V per octave, and things just sound out of tune if we work with only 256 levels. From what I can see the standard gpiod node uses a nodejs library called js-pigpio, which seems to be unmaintained: dceejay raised an issue more than two years ago which hasn't been looked at, and there have been no updates for three years apart from badges in the README.md.
There is another nodejs library which I've been looking at, called pigpiod-client, under more active development. It accesses gpiod in the same way, via the socket library.
Neither of these two libraries currently support hardware PWM, but I've done a bit of work on pigpiod-client to add it and it works, giving two channels of accurate hardware PWM at high frequencies (I've checked them with an oscilloscope). The author of pigpiod-client is happy to approve my PR once I've made a couple of minor changes to names.
Once that's been accepted I'd like to be able to wrap it in node-red goodness. For this I think there are three options:
- Add just the hardware PWM functionality to the existing node-red-gpiod using the new library, leaving all the other functionality the same with the old library. I'm not 100% sure this will work, but I don't see why not on first reading.
- Move the existing node-red-gpiod entirely over to the new library pigpiod-client. This could include setting the PWM frequency for the standard DMA PWM, that is not currently implemented. I guess there is a risk here that existing functionality may break for subtle reasons.
- Write an entirely independent node-red-contrib from scratch, doing just hardware PWM.
My personal order of preference would be 1-3-2. If dceejay is happy to consider a PR then I'll look at doing 1. If a PR is unlikely to be accepted in any case I'll go straight to 3. If a PR would only be accepted for a full re-work then I'll consider doing 2.
What do you think?
1 Like
Hi,
as you point out there is no activity on the current underlying library so my preference would be 2-1-3, so that the existing node moves over to the maintained library and adds the PWM functionality you require.
Ok I’ll take a look at refactoring the node. A few questions:
-
Are there any regression tests available, or examples of flows that should work?
-
Are there any coding standards in place e.g. eslint rules to apply?
-
Should I be trying to add the v1 “done” callbacks at the same time? Or is it better to separate out the issues?
1 Like
Hi,
- No not really - main tests are purely functional (ie on real hardware)
- yes - there are .jshintrc and .jscsrc fiels in the top level of the node-red-nodes project
- Probably easier to keep separate - but if you get it in I won't complain.
