Thanks, Joe.  I think there's something to be said for the Winwarbler approach, precisely because I already have lead time set up in N1MM.  OTOH, it wouldn't be that hard to zero that out if the Winkeyer itself can be set up with the right lead time, regardless of software used.  I have 3.1, so it's just a matter of finding out how to do it.

73, Pete N4ZR
Check out the new Reverse Beacon Network
web server at <http://beta.reversebeacon.net>.
For spots, please use your favorite 
"retail" DX cluster.

Which version of WinKeyer do you have?

Check the K1EL manual:
<https://www.k1elsystems.com/files/WKUSB_Manual_v1.3.pdf>
for the stand-alone command set (Command L) or use the WK3tools
editor to set the stand-alone parameters. Be sure to get WK3tools
version 5.2:
<https://hamcrafters2.com/WinKeyer_31.html>

Winwarbler provides a way to set lead-in and tail times when WW
is controlling the WinKeyer (just as N1MM+) but WinKeyer resets
the lead-in and tail times to the default standalone values every
time the "host" mode (application) closes.

73,

... Joe, W4TV

Thanks, Dave - I haven't even installed Winwarbler up until now, because I don't operate digital modes to speak of.  Does this mean that I will have to start Winwarbler to enable the lead-in delay.

73, Pete N4ZR
Check out the new Reverse Beacon Network
web server at <http://beta.reversebeacon.net>.
For spots, please use your favorite 
"retail" DX cluster.

+ AA6YQ comments below

I have a small mystery; I type in W4FWC into the DXKeeper Capture window and click Lookup; it show me the name as "The", in Granite City TN. Meanwhile Pathfinder says its John in Granite City IL.

My log does not have any entry for that callsign so it is not grabbing old date from there...

+ Which callbook have you selected on the Callbook tab of DXKeeper's Configuration window?

73,

Dave, AA6YQ

+ AA6YQ comments below

I just had a report during a QSO of truncation of the first character of my CW. I was running DXKeeper and Commander. Since 99 percent of my QSOs are in contests with N1MM, I've relied on provision in that software for some lead time between PTT and the first cw, using a Winkeyer. Is there anything similar in DXlab? have looked through the help for both and don't see anything similar, but as complete as the software and its documentation are, it's hard to imagine that this problem hasn't been dealt with before now.

+ On the Timing subpanel on the WinKey panel on the CW tab of WinWarbler's Configuration window, the "first extension" setting does that. See

https://www.dxlabsuite.com/winwarbler/Help/CWSettings.htm#WinKey%20panel

73,

Dave, AA6YQ

I have a small mystery; I type in W4FWC into the DXKeeper Capture window and click Lookup; it show me the name as "The", in Granite City TN. Meanwhile Pathfinder says its John in Granite City IL.

My log does not have any entry for that callsign so it is not grabbing old date from there...

Clues anyone?

-- 
Thanks & 73 de Dave, W5SV

WW -> Config -> CW ...

PTT field in the left column ... check "assert PTT during CW"
PTT Lead time is what you want ...

Further data in "Help" from that page ... you probably want a
20 ms lead.

73,

... Joe, W4TV

+ by "all skimmer spots", you means "spots whose spotting callsigns
ends with -# or -@ correct?

Yes, RBN spots reported by the general network in addition to a direct
connection to the RBN network.

+ Don’t the spot notes in an FT8 spot like

2021-12-27 01:08 de KA5M (NA-M) on 7074.0 : ON8KW called by KA5M reported SNR = +00 >
+ convey useful information to stations seeking to work ON8KW? They indicate that KA5M is copying ON8KW with an SNR of 0, indicating
that stations near KA5M should expect to copy ON8KW with a
reasonably strong signal. Granted, the spot notes don't describe
KA5M's antenna...

"Called by KA5M" is redundant as KA5M is the spotting station.
"Reported SNR = + 00" is no more useful than the "5 dB" in the
RBN reports. At the very least, the verbosity of "Reported SNR ="
is completely wasteful. I also think the "third party" spots:

2021-12-27 01:08 de W1AA (NA-E) on 7074.0 : ON8KW
called by AA6YQ reported SNR = +00

are probably not useful at all in the spot history (unless AA6YQ
happens to be a local). Even then, with his 2 element yagi at
100 feet +, his reports might be 10-15 dB higher than another
station with a 30' high dipole or 43' vertical.

73,

... Joe, W4TV


On 2021-12-26 8:18 PM, Dave AA6YQ wrote:

+ AA6YQ comments below
A more aggressive stress test would be to replace the three "normal" DX Clusters with the full four - all of which forward RBN spots - in addition to DX Summit and your local instance of WSJTX.
+ Because SpotCollector receives spots from multiple sources, it has the ability to quickly detect identical spots received from different sources, and discard an already-processed spot without searching for an existing entry in the Spot Database. Thus your suggestion would generate some additional stress, but not much.

Thus I propose to modify the next version of SpotCollector to not
retain the spot frequency and spot notes from an RBN spot source when
the "Record individual spot information" option is enabled.

That sounds like a good idea. However, I recommend applying it to all skimmer spots, including those forwarded by normal clusters.
+ by "all skimmer spots", you means "spots whose spotting callsigns ends with -# or -@ correct?
I would also recommend not retaining spot frequency (offset) and signal strength of spots from WSJTX and/or JT-Alert for the same reasons as eliminating that information on Skimmer spots. With WSJTX/JT Alert, the "base" frequency, mode and any F/H indication should be sufficient.
+ Don’t the spot notes in an FT8 spot like
2021-12-27 01:08 de KA5M (NA-M) on 7074.0 : ON8KW called by KA5M reported SNR = +00
+ convey useful information to stations seeking to work ON8KW? They indicate that KA5M is copying ON8KW with an SNR of 0, indicating that stations near KA5M should expect to copy ON8KW with a reasonably strong signal. Granted, the spot notes don't describe KA5M's antenna...
73,
Dave, AA6YQ

I just had a report during a QSO of truncation of the first character of my CW.  I was running DXKeeper and Commander.  Since 99 percent of my QSOs are in contests with N1MM, I've relied on provision in that software for some lead time between PTT and the first cw, using a Winkeyer.   Is there anything similar in DXlab?  have looked through the help for both and don't see anything similar, but as complete as the software and its documentation are, it's hard to imagine that this problem hasn't been dealt with before now.

TIA and HNY

73, Pete N4ZR
Check out the new Reverse Beacon Network
web server at <http://beta.reversebeacon.net>.
For spots, please use your favorite 
"retail" DX cluster.

+ AA6YQ comments below

A more aggressive stress test would be to replace the three "normal" DX Clusters with the full four - all of which forward RBN spots - in addition to DX Summit and your local instance of WSJTX.

+ Because SpotCollector receives spots from multiple sources, it has the ability to quickly detect identical spots received from different sources, and discard an already-processed spot without searching for an existing entry in the Spot Database. Thus your suggestion would generate some additional stress, but not much.

Thus I propose to modify the next version of SpotCollector to not
retain the spot frequency and spot notes from an RBN spot source when
the "Record individual spot information" option is enabled.

That sounds like a good idea. However, I recommend applying it to all skimmer spots, including those forwarded by normal clusters.

+ by "all skimmer spots", you means "spots whose spotting callsigns ends with -# or -@ correct?

I would also recommend not retaining spot frequency (offset) and signal strength of spots from WSJTX and/or JT-Alert for the same reasons as eliminating that information on Skimmer spots. With WSJTX/JT Alert, the "base" frequency, mode and any F/H indication should be sufficient.

+ Don’t the spot notes in an FT8 spot like

2021-12-27 01:08 de KA5M (NA-M) on 7074.0 : ON8KW called by KA5M reported SNR = +00

+ convey useful information to stations seeking to work ON8KW? They indicate that KA5M is copying ON8KW with an SNR of 0, indicating that stations near KA5M should expect to copy ON8KW with a reasonably strong signal. Granted, the spot notes don't describe KA5M's antenna...

73,

Dave, AA6YQ

+ AA6YQ comments below

I automatically upload each Q to Club Log. I have "Auto upload" and "Slow net" checked. (because my internet is via WiMAX)

After about every 4th or 5th log entry, I get a DXKeeper window popup stating: "Upload QSO to Club Log succeeded: updated QSO"

This happens with and without the "Slow net" box checked.

I'm unable to log another QSO until I click OK to clear the popup box.

How can I prevent this box from showing up? (besides stopping auto uploading)

+ So that I can see what's going on, please do the following:

1. on the Configuration window's General tab, check the "Log debugging info" box

2. after logging new QSOs has produced both responses: no popup window, and the "Upload QSO to Club Log succeeded: updated QSO" popup window,

2a. on the Configuration window's General tab, uncheck the "Log debugging info" box

2b. attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ

+ AA6YQ comments below

Wrapped up a good day updating my DXKeeper log with recent QSLs and addressing Sync errors both from LoTW and EQSL.

+ What was responsible for the Sync errors?


This effort did generate a couple of questions/observations related to Russian Oblasts. Running DXKeeper 16.4.0.

Frequently in my log the Russian Oblasts are incorrect and need updating according to the downloaded LoTW information. I direct the LoTW update to tell me about all of the issues in a report rather than correct them one by one.

In one case I wanted to update 86 QSOs with RU1A changing the oblast from (SP) to what LoTW provides (LO). Note, I attempted to confirm LO is correct. I did find a reference that RU1A, in particular, requires an Oblast exception, LO instead of what would normally be SP.

+ The RDA database indicates the RU1A is in Oblast LO (Leningradskaya) and District LO-31 (Luzhsky Area).

My question is which "Item Name" does the oblast field corresponded to in the pull down under the Advanced Tab?

+ STATE

+ As described in

https://www.dxlabsuite.com/dxkeeper/Help/Items.htm#state

+ this item captures the QSO's "Primary Administrative Subdivision" which for QSOs with stations in UA, UA0, UA2, and R1FJL records the QSO's' Oblast code.

+ This is describe in the reference documentation in

https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#AP%20SRR%20Russian%20Oblast%20reports

+ and

https://www.dxlabsuite.com/dxkeeper/Help/AwardInfo.htm

I didn't see anything that looked similar. Knowing this I could bulk "Modify the QSOs in the Log Page Display".

Referring to the help detail, I note that the Oblast and district fields are not documented in the table describing the fields in the Awards tab. Oversight?

+ The table entry in

https://www.dxlabsuite.com/dxkeeper/Help/AwardInfo.htm

+ notes that the "Textbox Caption" varies by DXCC entity, but the "Item Name" (which you would use in an SQL Query or in the "Advanced Sorts, Filters, and Modifiers" window's "Modify QSOs" panel) does not vary by DXCC entity.

+ If you've selected a QSO with UA, UA0, UA2, or R1FJL on the Main window's "Log QSOs" tab, the STATE item's caption will be "oblast", and the CNTY item's caption will be "district'. The Capture window works similarly.

+ If you have the RDA database installed in DXView, the CBA function can be used to populate missing Oblasts and Districts:

https://www.dxlabsuite.com/dxkeeper/Help/UpdateLogFromCallbook.htm

+ I see that with the RDA database installed, DXView erroneously reports that RU1A's Oblast is SP and its District is LO-31. I will correct this defect in the next version of DXView. This defect is not present in either SpotCollector or DXKeeper.

73,

Dave, AA6YQ

I automatically upload each Q to Club Log.   I have "Auto upload" and "Slow net" checked.  (because my internet is via WiMAX)

After about every 4th or 5th log entry, I get a DXKeeper window popup stating: "Upload QSO to Club Log succeeded: updated QSO"     

This happens with and without the "Slow net" box checked.

I'm unable to log another QSO until I click OK to clear the popup box.

How can I prevent this box from showing up?   (besides stopping auto uploading)

Thanks for any help.


73
Glenn W0GJ

...via the Databases tab on DXView's Configuration window.

73,

Dave, AA6YQ

To stress-test the next version of SpotCollector, I configured 6
spot sources: the RBN, three "normal" DX Clusters (K1RFI, EI7MRE,
N6WS, the DX Summit web cluster, and an instance of WSJT-X running
on 40m driven by a Flex 6500 and a 2-element 40m Yagi pointed at 45
degrees from my QTH in the Boston Massachusetts area.

A more aggressive stress test would be to replace the three "normal"
DX Clusters with the full four - all of which forward RBN spots -
in addition to DX Summit and your local instance of WSJTX.

Thus I propose to modify the next version of SpotCollector to not retain the spot frequency and spot notes from an RBN spot source when
the "Record individual spot information" option is enabled.

That sounds like a good idea. However, I recommend applying it to all
skimmer spots, including those forwarded by normal clusters. I would
also recommend not retaining spot frequency (offset) and signal
strength of spots from WSJTX and/or JT-Alert for the same reasons as
eliminating that information on Skimmer spots. With WSJTX/JT Alert,
the "base" frequency, mode and any F/H indication should be sufficient.

73,

... Joe, W4TV


On 2021-12-26 4:49 PM, Dave AA6YQ wrote:

The Remote Beacon Network RBN), whose home page is here
http://reversebeacon.net/
conveys the aggregated output of CW Skimmer receivers located around the world. It provides a "telnet feed" that can be used as one
of SpotCollector's Spot Sources, using a host address of telnet.reversebeacon.net and a port of 7000. An introduction to using the
RBN with SpotCollector is here:
http://www.dxlabsuite.com/RBN/index.htm
To stress-test the next version of SpotCollector, I configured 6 spot sources: the RBN, three "normal" DX Clusters (K1RFI, EI7MRE,
N6WS, the DX Summit web cluster, and an instance of WSJT-X running on 40m driven by a Flex 6500 and a 2-element 40m Yagi pointed at
45 degrees from my QTH in the Boston Massachusetts area.
On connecting to the RBN yesterday afternoon, it reported that it was conveying ~11,000 spots per hour (~180 spots per minute, 3
spots per second).
I have SpotCollector configured to automatically keep the Spot Database pruned to the entries for stations active during the last 24
hours; if I were actively pursuing a needed station, I would add its callsign to the Special Callsign List with a noprune tag in
order to accumulate a longer operating pattern in order to optimize my listening frequencies and times.
Over the course of yesterday evening and today's early morning, the size of the Spot Database peaked at just over 1 gigabyte. At
present (2130Z), there are ~35,000 entries now present in the Spot Database Display - ~25,000 of which were last updated by an RBN
spot - and the Spot Database size is ~175 megabytes.
Note that the solar flux index (SFI) at 130 is close to an all-time high for this solar cycle, the geomagnetic K-index is 0 (very
quiet conditions), there's a popular Russian DX contest underway, and it's Christmas weekend.
With the "Maximum age of valid incoming spots" option set to 60 minutes, SpotCollector is consuming 10%-15% of available CPU cycles
(Intel i7-4770K @ 3.5 GHz, 16GB RAM). My system remains responsive under this load, except when the CPU load spikes at the top of
each hour when SpotCollector's automatic pruning mechanism almost always triggers compaction of the Spot Database to recover the
storage associated with the Entries deleted during the pruning.
I have SpotCollector's "Record individual spot information" option enabled, which means that every Spot Database Entry retains the
cumulative text of the last ~200 or so spots of the callsign associated with the Entry. This information can be displayed by
right-clicking an Entry and choosing "Display spots of ..." from the pop-up menu. The spot notes for a station operating split often
include the station's most recent QSX frequency, which can be helpful in determining the station's "listening pattern" before
jumping into the pileup.
With the RBN as a spot source, spot notes contain signal strength at the receiving station in db, and CW speed in words per minute.
LY2PX was first spotted at 1632Z today on 40m CW. The Spot Database Entry for LY2PX has recorded 132 spots contributed by 66
different spotting stations; here's are the most recent 10:
2021-12-26 20:48 de HB9BXE (EU) on 7,021.0 : CW 5 dB 25 WPM CQ
2021-12-26 20:48 de KM3T (NA-E) on 7,021.0 : CW 6 dB 25 WPM CQ
2021-12-26 20:49 de EY8ZE (AS) on 7,021.0 : CW 7 dB 25 WPM CQ
2021-12-26 20:49 de DL3DTH (EU) on 7,021.0 : CW 11 dB 25 WPM CQ
2021-12-26 20:49 de DK9IP (EU) on 7,021.0 : CW 8 dB 25 WPM CQ
2021-12-26 20:49 de UA4M (EU) on 7,021.0 : CW 4 dB 25 WPM CQ
2021-12-26 20:49 de SA1CCQ (EU) on 7,021.0 : CW 7 dB 25 WPM CQ
2021-12-26 20:49 de DO4DXA (EU) on 7,021.0 : CW 5 dB 25 WPM CQ
2021-12-26 20:50 de EA1URA (EU) on 7,021.0 : CW 2 dB 25 WPM CQ
2021-12-26 20:50 de PY7ZC (SA) on 7,021.0 : CW 11 dB 26 WPM CQ
While the information in these spot notes is certainly of interest to LY2PX, as it shows the strength of his signal is various
locations (but with different receiving capabilities at those locations), the spot notes contain no information of value to the DXer
seeking to work LY2PX.
Since each Spot Database Entry shows the its station's most recently spotted frequency, the " on 7,021.0 " contained in each of
the above entries is also of no value
Thus I propose to modify the next version of SpotCollector to not retain the spot frequency and spot notes from an RBN spot source
when the "Record individual spot information" option is enabled. This would save 31 characters per spot; for LY2PX's 132 retained
spots, that would save ~4,000 bytes. With ~25,000 Spot Database Entries populated by the RBN, my Spot Database size would be reduced
by ~100 megabytes - more than half its current size!
Note that this proposal would not prevent you from using the RBN to see signal strength reports for your transmitted signal: uncheck
the RTB spot source's "Hide" and "Ann/Talk" boxes on the Configuration window's "Spot Source" tab, and a window showing incoming RBN
spots will appear; call CQ on a clear frequency, and this window will show you where you're being heard, and with what signal
strength.
The savings in absolute Spot Database size will likely be smaller during less popular operating periods, but every contribution to a
reduction in resource consumption helps - especially when there's no loss of useful functionality
Objections to this proposal, or better ways of accomplishing its objective would be appreciated.
A historical note: SpotCollector was first developed around 1991 to collect and aggregate manually-posted spots from a VHF packet
cluster (K6LLK) running at 1200 baud. Back then, one DX spot per minute seemed frenetic; 30 years later, the RBN is delivering 3
spots per second.
73,
Dave, AA6YQ

The Remote Beacon Network RBN), whose home page is here

http://reversebeacon.net/

conveys the aggregated output of CW Skimmer receivers located around the world. It provides a "telnet feed" that can be used as one
of SpotCollector's Spot Sources, using a host address of telnet.reversebeacon.net and a port of 7000. An introduction to using the
RBN with SpotCollector is here:

http://www.dxlabsuite.com/RBN/index.htm

To stress-test the next version of SpotCollector, I configured 6 spot sources: the RBN, three "normal" DX Clusters (K1RFI, EI7MRE,
N6WS, the DX Summit web cluster, and an instance of WSJT-X running on 40m driven by a Flex 6500 and a 2-element 40m Yagi pointed at
45 degrees from my QTH in the Boston Massachusetts area.

On connecting to the RBN yesterday afternoon, it reported that it was conveying ~11,000 spots per hour (~180 spots per minute, 3
spots per second).

I have SpotCollector configured to automatically keep the Spot Database pruned to the entries for stations active during the last 24
hours; if I were actively pursuing a needed station, I would add its callsign to the Special Callsign List with a noprune tag in
order to accumulate a longer operating pattern in order to optimize my listening frequencies and times.

Over the course of yesterday evening and today's early morning, the size of the Spot Database peaked at just over 1 gigabyte. At
present (2130Z), there are ~35,000 entries now present in the Spot Database Display - ~25,000 of which were last updated by an RBN
spot - and the Spot Database size is ~175 megabytes.

Note that the solar flux index (SFI) at 130 is close to an all-time high for this solar cycle, the geomagnetic K-index is 0 (very
quiet conditions), there's a popular Russian DX contest underway, and it's Christmas weekend.

With the "Maximum age of valid incoming spots" option set to 60 minutes, SpotCollector is consuming 10%-15% of available CPU cycles
(Intel i7-4770K @ 3.5 GHz, 16GB RAM). My system remains responsive under this load, except when the CPU load spikes at the top of
each hour when SpotCollector's automatic pruning mechanism almost always triggers compaction of the Spot Database to recover the
storage associated with the Entries deleted during the pruning.

I have SpotCollector's "Record individual spot information" option enabled, which means that every Spot Database Entry retains the
cumulative text of the last ~200 or so spots of the callsign associated with the Entry. This information can be displayed by
right-clicking an Entry and choosing "Display spots of ..." from the pop-up menu. The spot notes for a station operating split often
include the station's most recent QSX frequency, which can be helpful in determining the station's "listening pattern" before
jumping into the pileup.

With the RBN as a spot source, spot notes contain signal strength at the receiving station in db, and CW speed in words per minute.
LY2PX was first spotted at 1632Z today on 40m CW. The Spot Database Entry for LY2PX has recorded 132 spots contributed by 66
different spotting stations; here's are the most recent 10:

2021-12-26 20:48 de HB9BXE (EU) on 7,021.0 : CW 5 dB 25 WPM CQ
2021-12-26 20:48 de KM3T (NA-E) on 7,021.0 : CW 6 dB 25 WPM CQ
2021-12-26 20:49 de EY8ZE (AS) on 7,021.0 : CW 7 dB 25 WPM CQ
2021-12-26 20:49 de DL3DTH (EU) on 7,021.0 : CW 11 dB 25 WPM CQ
2021-12-26 20:49 de DK9IP (EU) on 7,021.0 : CW 8 dB 25 WPM CQ
2021-12-26 20:49 de UA4M (EU) on 7,021.0 : CW 4 dB 25 WPM CQ
2021-12-26 20:49 de SA1CCQ (EU) on 7,021.0 : CW 7 dB 25 WPM CQ
2021-12-26 20:49 de DO4DXA (EU) on 7,021.0 : CW 5 dB 25 WPM CQ
2021-12-26 20:50 de EA1URA (EU) on 7,021.0 : CW 2 dB 25 WPM CQ
2021-12-26 20:50 de PY7ZC (SA) on 7,021.0 : CW 11 dB 26 WPM CQ

While the information in these spot notes is certainly of interest to LY2PX, as it shows the strength of his signal is various
locations (but with different receiving capabilities at those locations), the spot notes contain no information of value to the DXer
seeking to work LY2PX.

Since each Spot Database Entry shows the its station's most recently spotted frequency, the " on 7,021.0 " contained in each of
the above entries is also of no value

Thus I propose to modify the next version of SpotCollector to not retain the spot frequency and spot notes from an RBN spot source
when the "Record individual spot information" option is enabled. This would save 31 characters per spot; for LY2PX's 132 retained
spots, that would save ~4,000 bytes. With ~25,000 Spot Database Entries populated by the RBN, my Spot Database size would be reduced
by ~100 megabytes - more than half its current size!

Note that this proposal would not prevent you from using the RBN to see signal strength reports for your transmitted signal: uncheck
the RTB spot source's "Hide" and "Ann/Talk" boxes on the Configuration window's "Spot Source" tab, and a window showing incoming RBN
spots will appear; call CQ on a clear frequency, and this window will show you where you're being heard, and with what signal
strength.

The savings in absolute Spot Database size will likely be smaller during less popular operating periods, but every contribution to a
reduction in resource consumption helps - especially when there's no loss of useful functionality

Objections to this proposal, or better ways of accomplishing its objective would be appreciated.

A historical note: SpotCollector was first developed around 1991 to collect and aggregate manually-posted spots from a VHF packet
cluster (K6LLK) running at 1200 baud. Back then, one DX spot per minute seemed frenetic; 30 years later, the RBN is delivering 3
spots per second.

73,

Dave, AA6YQ

+ AA6YQ comments below

Is there a way to print the logbook page thats displayed after you click view submission?

Yes, click the Report button (will open in Notepad and can be saved or printed).

+ The Report button (above the Log Page Display on the Main window's "Log QSOs" tab) will generate a printable file showing all QSOs in the (filtered) Log Page Display - no matter which function did the filtering and/or sorting.

73,

Dave, AA6YQ

+ AA6YQ comments below

Based on history, XW-3 will be the likely name.
The interchangeable "XW-3" and "CAS-9" naming (sometimes it's XW-3 (CAS-9), sometimes it's just CAS-9) makes this a bit of a toss-up.

ARRL recently (within the last week or so) pushed an update to add a pair of other sats (MAYA-x if I remember correctly), so they'll have to push out an update for this as well.
(I've notified them of the new satellite. Seems like that's not something anyone at the ARRL is monitoring

+ Thanks, Rick; I'll wait to see what's specified in the Configuration Data update.

Dave